Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 23 Next »

How to access:

Manually create Cobundu users in Studio

Add new users in Studio by using the button "add new"

Remember that a Cobundu user needs to be linked to an IWMS user in order to have certain rights (eg to make a reservation or to book a ticket). So make sure the users exist in MCS first, this way you can link them during the upload.

 

UID (Unique ID within Studio) and sumorea e-mail address will be created using

  • (short) tenant
  • first name
  • last name

 

Login to Cobundu (Studio, Go, touchpoints) is possible via either

  • UID
  • sumorea e-mail address
  • e-mail address

 

Upload of multiple users at once (batch upload) is possible using the import-functionality. Check import_cobundu_users.xls as example:

  • all fields are mandatory (incl default password to start with)
  • document may not contain hyperlinks (so better to set e-mail address as text)

 

Automatic creation of Cobundu users

Initially designed as SSO (Single Sign-On) for Cobundu, the set-up of Cobundu SSO has the hidden advantage that for every (new) Cobundu user signing in, upon first login, Cobundu creates an account on-the-fly and the user can start using the system.

A user logging in with Cobundu ID (tenant.ID) is recognized as being part of a tenant where SSO has been setup and Cobundu will automatically create a Cobundu account.

Prerequisites for Automatic creation of Cobundu users, see section "Cobundu SSO".

Cobundu SSO

Cobundu SSO is available for Go.cobundu.com and Personal Assistant.

Prerequisites for Cobundu SSO

  • MCS account for user must exist
    • Ideally, an HR interface takes care of automatic creation of MCS users
    • In case the logged in user doesn’t exist in MCS, the user will not be able to use any MCS-dependant features like making reservations.
  • Identity Provider Mapping (receiving following attributes from the identity provider: "MCS login ID", "First Name", "Last Name" and "E-Mail“)
    • In case the “MCS login ID” attribute is not correctly mapped, the user will not be able to use any MCS-dependant features like making reservations.

How is it set up?

Cobundu supports SAML 2.0 protocol which is the industry standard among all up-to-date integrations. See SSO SAML 2.0 for a general understanding of how SSO works.
The SSO configuration from MCS cannot be re-used on Cobundu. These are 2 separated apps from the Identity Provider perspective, and each requires an independent SSO federation setup.

Development takes 2 MDs (incl PM).  The estimate depends on configuration and regulations on the Identity Provider in terms of supported SAML 2.0 options and features, as well as on the maturity of IT staff that is responsible for configuring federation on the customer side. The estimate does not cover HR interface setup on MCS (user accounts sync), which is a prerequisite for SSO to work on Cobundu.

Contact applicationintegration@spacewell.com for a more detailed quote or to plan your next project.

How does it work?

A user logging in with Cobundu ID (tenant.ID) is recognized as being part of a tenant where SSO has been setup and Cobundu will automatically create a Cobundu account. The user can proceed to login.

A user logging in with e-mail address is now also supported: It uses a whitelist of e-mail providers (eg @spacewell.com or @mcs.be) to check the tenant. To whitelist an e-mail domain, add it to Settings > SAML SSO > "Allowed email domains (comma separated)" (underneath "Auto-Create user").

On GO, if your customer has SSO installed and you want to bypass (and login using your Cobundu ID), go to https://go.cobundu.com/no-sso; select "Log in with your Cobundu credentials"; then log in with your Cobundu ID and password.

 

Keep into account that a side effect from SSO is also creating users, but that's as far as the user management goes. There is no update done, no deletion or deactivation. If a user is set to disabled in MCS, the consequence will be that the Cobundu user is still active, but does not have any MCS rights anymore: the user can login to Cobundu touchpoints and browse reservable rooms, floorplans etc, but as soon as they want to make a reservation or book a ticket, this will not be possible (because they don't have the correct MCS rights anymore).

 

More information on Cobundu SSO can be found in this presentation (keep in mind: Cobundu SSO only available for Go and Personal Assistant)

 

Presentation in French:

 

Roles & Profiles

Roles and Profiles for each tenant can be found/ are described on Studio (scroll to the bottom of the tenant: under Users, you'll find “Roles & Profiles”).

 

  • “No roles found, unprivileged user”: user can access End-user Cobundu touchpoints (GO + PA)
  • “Admin” role is needed to access Studio (will only give access to current tenant),  KioskApp DeviceControl

! With great power comes great responsibility: make sure the Admin-user is aware of the Studio basics. Having access to Studio = having access to the Settings page + Sensor Devices mapping + Floorplan config + ... => a basic training in Studio is needed before access can be given.

  • "Developer" role is assigned typically to users who have the rights to view/consume/integrate COBUNDU APIs with touchpoints. As these users can also be external developers who work on integrating COBUNDU with their systems, such users should not have access to COBUNDU touchpoints. On GO, users with only developer role are automatically redirected to the API documentation upon login and cannot use any other front-end features.On Personal Assistant, an alert will be shown and the user will not be allowed to continue.

Depending on the needs per customer, other roles can be added to the tenant (select "Add New"); eg Work Assistant roles that can access different Workorder overviews.

 

  • No labels