This page contains all the frequently asked questions regarding single sign-on. If there is something else you want to know which isn't listed here, please reach out to our Customer Support team via our Help Centre, or at support@immersivelabs.com
Contents:
-
SSO Set Up
- Does Immersive support SP and IDP initiated SAML SSO?
- How can I update my expiring (X.509) certificate?
- Can I use the same SSO for a second Immersive organization or department?
- Can I manage teams using SSO?
- Can multi-factor authentication (MFA) or Time-based one-time password (TOTP) be implemented with SSO?
- What is the authentication flow?
- Does Immersive support Single Log Out (SLO)?
- SP-Initiated SLO
- IdP-Initiated SLO
- User Access
- User Accounts
- Personalization & customization
- Issues & Troubleshooting
Single sign-on (SSO) set-up
For more information on the basic set-up, please refer to the SSO Set Up Guide.
Does Immersive support SP and IDP initiated SAML SSO?
The Immersive One platform supports both SP and IdP initiated SAML SSO.
~-~
How can I update my expiring (X.509) certificate?
When your current certificate is about to expire, please contact Immersive Customer Support.
You will need to provide your new certificate, and a time and date that best suits you for when you want to make the change over.
~-~
Can I use the same SSO for a second Immersive organization or department?
Yes! We are able to leverage an additional attribute claim which can be used to identify which organization a customer will have access to.
This additional attribute claim is called:
urn:mace:dir:attribute-def:organisation-id
Note that this will require maintenance on your end (e.g., as new learners are added to your IdP, there needs to be a way of identifying which organization they belong to), but it is possible.
To enable this feature, contact Customer Support.
~-~
Can I manage teams using SSO?
Yes! Your teams will have to be managed through your organization's Identity Provider (IdP). If teams are captured in your IdP, users can be assigned teams automatically when they log in via SSO.
Teams will not need to be created in-platform.
This can be achieved via an additional attribute claim to identify the team(s) the user should be assigned to. The additional attribute claim is called:
urn:mace:dir:attribute-def:team-title
For more information on this, please read our guide to Optional SSO Setup - Team Management, or you can contact Customer Support.
~-~
Can multi-factor authentication (MFA) or Time-based one-time password (TOTP) be implemented with SSO?
The service provider (IdP) is responsible for the verification of a user. If your IdP supports MFA/TOTP features, you will be able to implement this there. We recommend working with your IdP to explore options that are available to you.
~-~
What is the authentication flow?
- User Initiates SSO: The user starts the SSO process by attempting to access a protected resource or application (the Service Provider or SP).
- SP Generates SAML Request: The Service Provider (SP) generates a SAML Authentication Request. This request asks the Identity Provider (IdP) to authenticate the user.
- Browser Relays SAML Request to IdP: The user's browser acts as an intermediary. It takes the SAML Request from the SP and sends it to the user's Identity Provider (IdP) (e.g., Azure AD, Okta, ADFS).
- IdP Authenticates User: The IdP verifies the user's identity. This might involve prompting the user to enter their credentials (username and password) or using an existing session.
- IdP Generates SAML Assertion: If authentication is successful, the IdP creates a SAML Assertion. This document contains information about the user, including their identity and attributes (e.g., email, name).
- IdP Sends SAML Assertion to Browser: The IdP sends the SAML Assertion back to the user's browser.
- Browser Relays SAML Assertion to SP: The user's browser forwards the SAML Assertion to the SP.
- SP Validates SAML Assertion: The SP validates the SAML Assertion to ensure it's from a trusted IdP and that the user is authenticated.
- SP Grants Access: If the assertion is valid, the SP grants the user access to the protected resource or application.
~-~
Does Immersive support Single Log Out (SLO)?
The platform currently offers partial support for Single Log Out (SLO) to help you manage secure session termination across your organization.
~-~
SP-Initiated SLO
We support Service Provider (SP)-initiated SLO. This means that when a user signs out directly from our platform, the system sends an SLO request to your Identity Provider (IdP). This request prompts the IdP to sign the user out of all other active sessions linked to that provider.
The SingleLogoutService Location and Response Location URLs are included in the SSO metadata for your region, available in the Single Sign On (SSO) Setup Guide.
~-~
IdP-Initiated SLO
Please note that the platform does not yet support IdP-initiated SLO. If your users sign out from your Identity Provider's dashboard, they may remain signed into our platform until their session expires via an Idle or Maximum timeout.
Note: If IdP-initiated SLO is a critical requirement for your organization, please contact your Customer Success Manager to discuss your needs.
User Access
How do I add users to the platform using SSO?
The SSO handles new user registration automatically. You do not need to take any action on your end.
You should direct users to the platform's login page. Your organization could have its own URL for this. Users can then select the 'Sign in with single sign on' button:
Note: this automatic process will only work as long as there are licenses available. If you'd like to add more licenses, please contact your Immersive Customer Success Manager or Account Manager.
~-~
Do I need to do anything so that existing users on the platform can use SSO?
This depends. The SSO uses 'email address' as the point of truth.
If you have users on the platform that have registered with an email address that does not match the email address available from your Identity Provider (IdP), such as Azure or Okta, for example, these email addresses need to be updated on the platform. This is so the users can be identified.
If the email addresses aren't updated, a second user account will be created for the user, with the email address stored in your IdP. There will not be any completion data associated with this new account. This will also use up a second license.
If you would like assistance with generating a list of your users and their respective email addresses, you can contact your Immersive Customer Success Manager or Account Manager. If you're an Organization Manager on the platform, you'll have access to this information yourself.
You can do this by navigating to Reports > Platform Activity > Data Explorer and selecting to explore your User List data:
~-~
How can I restrict Immersive access to only specific users via SSO?
You can implement this on your side in your Identity Provider (IdP). Create a security group within your IdP; a security group is a collection of users who are given permission to access specific applications.
The way this is created differs slightly in each IdP, but you'll need to create the security group and then add the users that you want to grant access to our platform to this group. You then assign/add the application (Immersive platform) to the group.
For assistance in the specifics of your IdP, we recommend contacting your internal technical team(s), or reaching out to your IdP directly.
~-~
Can I force my users to sign in via SSO only?
Yes, this can be enabled (or disabled) at any time. Please contact Customer Support for assistance.
We recommend letting your users know about this before we make this change to avoid confusion. Making this change will mean that they will not be able to log in using their Immersive credentials. Some of them may have been using this method previously, so it's best to communicate with them and let them know they will no longer be able to do so.
User Accounts
Does SSO update when user info changes in the IdP?
No, our current iteration of SSO does not yet support all these features. If a change to user information is made within your IdP, these changes also should be made on the Immersive platform.
To do so, please contact our Customer Support Team.
~-~
Will deactivated users be reactivated via SSO sign in?
No, signing in with SSO does not reactivate users. Users must be reactivated manually, via a SCIM sync, or an import.
Personalization & customization
Can we have our own bespoke URL name?
Of course! Please let us know what name you would like to use and when you would like us to have it in place by. If the URL you're after is already in use, we'll not be able to use it. Please do check this beforehand, but we'll let you know if this is the case.
We recommend you inform your users of the new URL name (if this has changed).
~-~
Can I customize the landing page with our own branding?
Yes, your landing page can be altered slightly to reflect your organization's branding. This customization is limited to:
- Background image
- Logo
- Bespoke colors and text
To do so, please contact our Customer Support Team.
Issues & Troubleshooting
Who can I speak to at Immersive for help with SSO?
Contact our Customer Support Team, who will be happy to assist you with your SSO queries.
~-~
What do the errors mean and how do I troubleshoot them?
If you are receiving errors, please use the table below to troubleshoot the more common causes. If you cannot see your specific error here, then please contact the Customer Support Team.
| Error message or issue | What does it mean? | Troubleshooting |
|
404 or 302 error Or another HTTPS-related error appearing |
This is likely to be an error on your end of the configuration in setting up Immersive as a Service Provider in your Identity Provider (IdP). | |
|
SSO login failures A user is selecting the landing page URL to login but:
|
This can either happen because:
Both issues are likely to be resolved by checking the attribute names and values within your IdP configuration - see the troubleshooting steps on the right for details. |
The attribute claims specified aren’t quite right (AttributeStatement.saml2:Attribute). There must be a minimum of two claims, and they must be named exactly as follows in order to work:
These claims must have corresponding values from your IdP (they cannot be null), otherwise the login will fail. Note: the email attribute claim value should be the full email address. -OR- Depending on the configuration you have required, there may be other claims that you have specified. If present, check that these claims are correct and that they also have been named correctly:
(Required for team mapping)
(Required for organization mapping) |
Comments
0 comments
Article is closed for comments.