SAML-based Single Sign-On Feature Overview

SAML-based Single Sign-On (SSO) is supported in LearningSpace.
LearningSpace uses a Shibboleth Service Provider (Shibboleth SP) software to accomplish this.

Elevate Healthcare handles the Shibboleth LS server-side configuration.

Once SAML SSO is enabled, and a LearningSpace user would like to log into LS, they will not be able to do that via the LS login page. When the user enters the LearningSpace URL, the Shibboleth SP (which runs on the main application server) will redirect them to the Identity Provider (IdP) login surface.

• On the IdP login page, the user enters their credentials (login name and password).

• After successful authentication, the IdP redirects the user to LearningSpace.
  During this phase, the IdP sends a unique attribute in a previously agreed format that is necessary for identifying the user (e.g., eduPersonPrincipalName, i.e., eppn, or eduPersonTargetedID, eduPersonAffiliation, etc.).

• In case this data is associated (‘mapped’) with a user’s UCID or email attribute in the LS database, LearningSpace will validate the session, and the user can log in.

  
  

The following types of IdPs have been successfully integrated with LearningSpace so far:

• Shibboleth (version 2 and version 3)

• OKTA

• ADFS

• AZURE AD

Requirements for setting up SAML SSO authentication

LearningSpace support requires the following:

1. Type and version of the customer’s IdP server (i.e., Shibboleth, ADFS, etc.) for an easier configuration method;

2. The unique attribute type and format that is used for user mapping and identification

3. The IdP server’s metadata.xml file or URL (idp-federation-metadata);

4. A test user created on the IdP side with access to LearningSpace application. With the help of such a test user, support engineers can test the SAML SSO authentication.
   To perform this test, the unique attribute’s value for the test user must be shared with support (which will be added to the test user’s UCID field in LearningSpace).

Installation and setup

1. LS Support team installs the Shibboleth SP on the main application server.

2. LS Support team generates the SP metadata (sp-metadata.xml file), and sends it to the customer.

3. The SP metadata needs to be imported by the customer on the IdP side (it is required to identify the Shibboleth SP).

Optional configurations

• Global logout: To configure it, the local IT must provide a global logout URL.

• Mixed Login: The site is accessed via the /email in the URL. (Example: https://<domain>/email or https://<ls_url>/email )

JIT (Just in Time Provisioning): To be able to create (or update) users in LS, the following claims containing the additional attributes are required:

• first name

• last name

• email address

• unique ID (it will be mapped to a hidden GUID and not UCID)

• group membership/role value (LS will assign the new user to a group and give privileges/roles to the user)

  Example: a new user with a "Learner" value for this attribute will be added to the "SSO Learners" group and the Learner role assigned.

Error messages

1. Value missing in the database
   This error occurs when a user can log in to the client-side IdP, the IdP sends the user's unique ID to LearningSpace, but LS cannot find the user based on it.
   
   

   
   
   

   The reason could be that the value is not present in any of the user fields (email or UCID) in LS, and therefore, the user cannot be identified.
   
   

2. Value entered incorrectly (Case-sensitivity)

NOTE: The attribute's value sent to the database is CASE SENSITIVE. If entered incorrectly during SSO login, users will be directed back to the Dashboard (when trying to access Recording or Reports, etc.), and will get the following error: