Difficulty: expert
Content
Learning Objectives
After reading this article, you’ll be able to:
set-up your Active Directory for communication with Workplace
understand how Workplace SSO works
setup Workplace SSO to automatically assign roles to Workplace users
setup Workplace SSO to automatically create Workplace users
Workplace Smart Buildings Single Sign-On (SSO) is available for Workplace Web (GO), the Workplace App and Workplace back-end Studio.
Prerequisites
based on e-mail address
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 Workplace roles
It should be possible to identify the IDP based on the User’s email ID:
A specific email domain name (ex: @spacewell.com) can only be mapped with one IDP in our system.
How is it set up?
Workplace supports SAML 2.0 protocol which is the industry standard among all up-to-date integrations.
The SSO configuration from IWMS cannot be re-used on Workplace. These are 2 separated apps from the Identity Provider perspective, and each requires an independent SSO federation setup.
Contact your Spacewell Account Manager to have Workplace SSO set up.
How does it work?
Workplace Single Sign-On (SSO) is available for Workplace Web (GO), the Workplace mobile App, Outlook Room Finder Add-In and Workplace back-end Studio.
Spacewell employees can find more information on https://spacewell.atlassian.net/wiki/spaces/SUM/pages/178159642/Cobundu+SSO#How-it-works
First time login
Subsequent logins
Workplace will check when (on IDP side) the user has been authenticated for the last time by providing username and password.
<AuthnStatement AuthnInstant="2024-03-18T10:55:40.225Z"... (now - 120 seconds - maxAuthLifeTime) < AuthnInstant < (now + 120 seconds)
by default, there is a 120 seconds tolerance (there can always be a glitch or slight misalignment in time stamp)
maxAuthLifeTime = setting on Workplace in months/years. This setting can be used to extend the tolerance time frame
The authentication lifetime setting in Workplace should be configured to align with your identity provider's authentication lifetime timeout value.
"Maximum Authentication Lifetime“ setting can be specified in hours, days, months, years. The value needs to be higher than 0, and will be set to 2 years per default.
Login without SSO
If SSO is configured for your environment and you do not have a login within the Identity Provider, you need to follow a work-around:
How does IDP resolution work?
IDP resolution is the mechanism of redirecting the user to the correct SSO provider when there are multiple providers present. This happens based on the email domain of the user.
If there are multiple allowed email domains (linked to different providers) set up for the same tenant, and users try to log in to Workplace Experience:
some of will be redirected to the Azure Cloud of IDP1 based on the email domain
similarly, others will be redirected to the Azure Cloud of IDP2 based on the email domain
SSO issues
If a user is experiencing SSO issues, he will be brought to the “Login Without SSO” page, which allows login with Cobundu Credentials. Yet, this user does not know his Cobundu credentials.
He might then also see the “Password reset” feature, but password reset feature is disabled when SSO is enabled for a tenant AND user auto-creation is enabled AND the user who is asking for the reset is auto-created.
An e-mail will be send saying that password reset is not allowed.
Role Mapping (see Roles & Profiles)
We can map the roles from the customer IDP user-assigned roles with the Workplace Experience roles:
If a user logs in using SSO and has no Workplace 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 Workplace role as defined in the role mapping
If a user logs in using SSO and already has a Workplace account:
Based upon the AD Account Group ID passed via metadata, the user will be assigned a Workplace role as defined in the role mapping
When this feature is in use, it will overwrite any manual role-attributions.
To start using this feature, contact your Spacewell Account Manager.
Automatic creation of Workplace users
The set-up of Workplace SSO has the hidden advantage that for every (new) Workplace user signing in, upon first login, Workplace creates an account on-the-fly (both in Workplace Management and Experience) and the user can start using the system.
A user logging in with Workplace ID (tenant.ID) or e-mail address is recognized as being part of a tenant where SSO has been setup and Workplace will automatically create a Workplace account.
The Identity provider is considered as the single source of truth. In other words: if the user is created automatically, the information is managed externally.
To make sure Workplace is always up-to-date with the user information, at each login (of an automatically created user), the following attributes are checked and updated:
user first name
last name
IWMS ID
To start using this feature, contact your Spacewell Account Manager.
FAQ
How to test Workplace SSO setup?
On Workplace Web (GO), the Workplace App or Workplace back-end Studio:
User to provide Workplace user ID (or e-mail address, depending on set-up)
(Workplace will evaluate the account ID prefix, and know this login attempt needs to happen via SSO.) The user is redirected to the external SSO login screen.
After entering the credentials (assuming the Identity Provider approves): Workplace will automatically create a Workplace account (and link to the IWMS account).
The user will be able to use all relevant Workplace functionalities.
How does SSO treat Leavers in the company?
SSO is a Sign-on tool. It does not make any no updates on users nor does it handle deletion or deactivation. If a user is set to disabled in the IWMS, the linked Workplace user is still active, but does not have any IWMS rights anymore: the user can login to Workplace touchpoints and browse reservable rooms, floorplans etc, but as soon as they want to make a reservation, this will not be possible (because they don't have the correct IWMS rights anymore).
Troubleshooting
Check if the IWMS user is set up correctly
Does the user have the necessary rights?
Is the user enabled?
Check if the Workplace user is set up correctly
Is the Workplace user linked to the IWMS user?
Are any Roles assigned?
Is the user enabled?
If you’re testing the access of the user in Workplace, does the SSO page open?
If yes, then please check SSO with your IT department
If no, please contact Spacewell Support
What if the Auto-Create User field “Allowed email domains (comma separated)” is not editable (grey)?
“Allowed email domains” is a cross-tenant setting, and can only be managed with global super-accounts by Spacewell.
In some cases, it can even be greyed out for global super-accounts. This happens for example in special cases of custom setup with CMEK. This list then needs to be manually managed from the back-end.
Search