RLMS SAML Single Sign-On
** Please Note:
The implementation of SAML SSO requires the participation of your internal IT team. If you are using an HRIS interface to the RLMS, the group managing this must also be part of the project. Customers who are interested in using this feature should begin by discussing it with their IT leadership, who should be able to proceed with this documentation.
The majority of the configuration required to deploy SAML is performed on the client side. Relias engineering support will assist by providing feedback on logs. IdP vendors may also need to be engaged for configuration and support.
RLMS SAML does not support user provisioning, only single sign on. Customers must store the shared unique identifier for each user in the GUID field of the RLMS user profile. Customers should implement HRIS processes or bulk update their RLMS user profiles prior to implementing SAML.
** This document outlines the steps necessary to use the new SAML Single Sign-On in the RLMS.
For the SAML panel to show in the Customer's settings, the checkbox “Show SAML SSO Panel” needs to be checked for the site. A client will specifically need to request SAML to be turned on for them, and a Relias Learning Support representative will toggle this field. This request can be submitted to Relias Learning Support
Now that the SAML Panel is available, a user with administrative permissions can log in. The user needs to switch over to their Administrator profile, and click on the settings tab in the RLMS.
Once on the settings screen, navigate down to the panel entitled “SAML Single Sign-On Settings”.
Use SAML SSO – This should be checked if the organization would like their users to log in using SAML SSO. Important - While testing it is recommended you also check 'Show SAML Landing page' and 'Allow traditional Log In' to avoid locking users out during configuration.
Show SAML Landing Page – When this is checked, the user will be presented with a log in screen as opposed to being redirected immediately to the Identity Provider log.
Allow Traditional Log In – This determines whether the user can log into the RLMS with the normal log in screen should their SSO credentials fail. When this is checked, a link will appear on the splash screen as well, allowing them to bypass SSO and use the traditional log in.
User Lookup Key Name – The name of the field in the SAML request that contains the unique identifier of the user (which must exist in the user profile in the GUID field on the RLMS) that is being passed in from the Identity Provider. For example, in the image below, the Identity Provider has mapped the RLMS GUID to a field they have named “username”. This is required for the RLMS Consumer Service to process which user is trying to log in. User Lookup Key Name should be entered in lowercase.
Hosted Metadata File / Upload Metadata File – The radio buttons will toggle how the RLMS Consumer Service will communicate with the Identity Provider. The Identity Provider has two options:
- Hosted Metadata File – The Identity Provider will publish their Metadata XML file on their server, and provide a link for the RLMS Consumer Service to access the file.
- Upload Metadata File – The Identity Provider may upload their Metadata XML file directly into the RLMS for the Consumer Service to look up the values locally.
- *Note that once the file is uploaded, the values still need to be saved by clicking the save button at the top of the page.
Assertion Consumer Service URL – This is a read-only field that allows the user to copy and paste the URL in the box. The URL will be needed on the Identity Provider’s side to communicate with the RLMS SSO service.
Metadata XML File
The Metadata XML file is the key piece to communication between the Identity Provider, and the RLMS Consumer Service.
The two most important keys are below:
Certificate Key – This is the key of the <X509 Certificate> that resides on the Identity Providers server. The SSO transaction will not complete if the key in the XML file does not match the certificate on the server.
Clients Single Sign On Landing Page – This is used in the SSO handshake to tell the RLMS Consumer Service where it should redirect to on the Identity Providers Server for the user to log in. Example entry : <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://stubidp.kentor.se/" />
When the SSO request is sent to the Identity Provider, it will have the name “http://ReliasLearningAssertionConsumerService/<Org Name Here>”
TLS - 1.0
When using ADFS:
User lookup Key must be the claim type in Claim Descriptions
To get back to the RLMS How To Manual, please click here: The RLMS How-To-Manual