Setting up Single Sign On

SAML Set-Up

Trakstar Learn can integrate with various Identity Providers (IDP) via the SAML authentication approach. Learn will take on the role of the Service Provider (SP), which can initiate authenticate requests to the IDP to validate a user in a remote system to log them into their Learn account. This process is also known as Single Sign-On (SSO).

Requirements

The account owner(s) must have a valid and functional IDP such as OKTA, Salesforce, Microsoft Azure, G Suite (formerly called Google Apps), Feide, etc. Custom IDPs are acceptable as long as the IDP conforms to the SAML 2.0 standard.

Setup Process

Once all requirements are met, the account owner must contact their Trakstar Learn Customer Success Manager or customer support to set up SAML integration. Please have all of the following information available before contacting your CSM or customer support:

• Service Provider-Initiated Redirect URL: This URL is the location Learn will send the initial authorization request. This URL must be able to process SAML Redirect protocol (HTTP GET). When sending the response form, the generated page should do a POST back to the Assertion Consumer Service (ACS) URL. This URL is sent as part of the authorization request. 
  • Note: some higher security systems like Salesforce will require you to enter an ACS URL into the IDP mechanism, which will ignore the ACS URL sent in the authorization request. If the ACS URL is set correctly on the IDP side, this is fine. See more below about the ACS URL setup.
• IDP Issuer: This is a string that represents the identity of the IDP and can be found in the IDP setup.
• IDP Public Certificate: This is the public key corresponding to the private key that the IDP uses to sign the assertion requests. This should be an x.509 certificate that conforms to the SAML 2.0 specification. These certificates are usually self-signed and do not necessarily need to be issued by a certificate authority. This key can be transmitted to Learn in various forms (cert, pem, etc.). Note: please remember NOT to send your private key; you should not share that with anyone!
• Service Provider Issuer: This is a string that corresponds to the identity of the Learn Service Provider. This value defaults to “https://<subdomain>.learn.trakstar.com” but, can be overridden if necessary depending on the specific requirements for the IDP. The IDP administrators will need to enter this value for the SP Entity ID in their IDP setup.
• Login Button Text: (Optional) This text will display on the login button on the Learn Login Screen. The default text is “Login with company credentials” but may be set according to your wishes.
• Login Button Graphic: (Optional) As an alternative to the login button text, you may supply your login button graphic to be displayed on the Learn login screen. This graphic must be 201x86 pixels, where the upper 201x43 pixels is the normal button state, and the lower 201x43 pixels is the mouse-over button state.

Assertion Consumer (ACS) URL

The ACS URL usually takes on the form "https://<subdomain>.learn.trakstar.com/saml/acs." This ACS URL requires that the IDP send the RelayState variable passed to it with the authentication request to the IDP. This also implies that IDP-Initiated login requests must send the Learn Account ID as the RelayState variable when attempting to log a user into Learn.

An alternative is simply using the Learn portal subdomain name in the ACS URL. An example ACS URL would be "https://acme.learn.trakstar.com/saml/acs." In this case, “acme” is the company portal subdomain name. The RelayState is not required in this instance.

Please specify which solution you prefer during your conversation with your customer success manager or the Learn support team.

Learn User Authentication

The IDP must send the appropriate Subject ID to Learn as part of the authentication response to log a Learn user in. This is how Learn will know which user to log in to. Learn supports four different identification methods:

• User ID: This is the internal Learn User ID of the user to log in. The IDP-side must have associated their user records with these Learn internal IDs to support this. This is frequently done via the Learn public API.
• Email: This is the email address of the associated user in Learn. All user emails must sync with their corresponding Learn records for this method to work. If the email is not found in the Learn portal, login will fail.
• Username: This is the Learn username of the user to log in. The IDP-side must have the Learn username. This is useful if all Learn users are given the same usernames as the remote IDP system records. Again, this is frequently done via the Learn public API.
• Federated ID: This can be a remotely specified user ID. The Learn user records must have the federated ID entered for this to work.

Single Sign-On with Provisioning

Learn can automatically add users to your Learn account the first time they successfully sign in. First, you will need to let your Customer Success Manager know you want this turned on for your account. Second, please provide the following attributes in your SAML response:

"emailaddress"

"givenname"

"surname"

IDP Specific Documentation

• Azure Active Directory
• Bitium
• Okta