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 32 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 IWMS 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 Cobundu User Management 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)

UNKNOWN ATTACHMENT


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".

UNKNOWN ATTACHMENT

Cobundu SSO

Cobundu SSO is available for Go.cobundu.com, Studio.cobundu.com and Workplace App.

Prerequisites for Cobundu SSO

  • IWMS account for user must exist

    • Ideally, an HR interface takes care of automatic creation of IWMS users

    • In case the logged in user doesn’t exist in IWMS, the user will not be able to use any IWMS-dependant features like making reservations.

  • Identity Provider Mapping (receiving following attributes from the identity provider: "IWMS login ID", "First Name", "Last Name" and "E-Mail“)

    • In case the “IWMS login ID” attribute is not correctly mapped, the user will not be able to use any IWMS-dependant features like making reservations.

  • (optional) Mapping between Active Directory account groups with Cobundu roles

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 IWMS 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 IWMS (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 and Studio, 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 or https://studio.cobundu.com/no-sso; select "Log in with your Cobundu credentials"; then log in with your Cobundu ID and password.

Role Mapping (see Roles & Profiles)

Initially, SSO was creating users, but that's as far as the user management went. There is no update done, no deletion or deactivation. If a user is set to disabled in the IWMS, the consequence will be that the Cobundu user is still active, but does not have any IWMS 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 IWMSrights anymore).

We have now added a way to overcome this by providing a mapping table in Studio, where one can map the Active Directory account groups with Cobundu roles:

  • If a user logs in using SSO and has no Cobundu account yet

      • The user will be automatically created

      • Based upon the AD Account Group ID passed via metadata, the user will be created and assigned a Cobundu role as defined in the role mapping 

  • If a user logs in using SSO and already has a Cobundu account

      • Based upon the AD Account Group ID passed via metadata, the user will be assigned a Cobundu role as defined in the role mapping

This Feature can be turned on or off.


More information on Cobundu SSO can be found in this presentation (keep in mind: Cobundu SSO available for Go, Workplace app and Studio)


Presentation in French (2020):



Good to know

In the Workplace platform, users are automatically disabled after 3 wrong login attempts.
For more details on possible password security settings, see General settings.

  • No labels