SAML-based Single Sign-On Feature Overview

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

Elevate Healthcare takes care of the Shibboleth LS server-side configuration.

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

• After successfully completing the authentication, the IdP redirects the user to LearningSpace.
  During this phase, the IdP sends a unique attribute – in a previously agreed format – necessary for identifying the user in question (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.
   In order to be able to perform this test, the unique attribute’s value of the test user must be shared with the 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 necessary for identifying the Shibboleth SP).

Optional configurations

• Global logout: To be able to configure that, 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 who has a "Learner" value as 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 if a user can log in on the client-side IdP and the IdP sends the user's unique ID to LearningSpace, but LS cannot find the user based on that.

   

   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: