What Is Single Sign-On?
Single sign-on (SSO) allows users to log in to Seismic Learning through a third-party system's credentials.
Learning integrates with a few different SSO providers to allow easy access when users sign in via the specified provider.
How to Set Up Single Sign-On
Learning requires the below credentials to begin setting up SSO:
The identity provider’s target URL
The identity provider’s certificate (in .PEM or .cert format) or a raw certificate fingerprint
Important Note: Once Single Sign-On is initiated for a company's instance, the above URL metadata file becomes a live URL and contains information including the requested nameIDFormat, the service provider callback URL, the issuer name, and the SAML version.
Identity Provider Requirements
Custom SAML 2.0
Support SAML 2.0
Support passing back an email address or UID for the users’ Name ID
Support passing back the following source attributes (please map to our default names):
First Name (urn:oid:2.5.4.42)
Last Name (urn:oid:2.5.4.4)
Nickname – optional
Email address (urn:oid:0.9.2342.19200300.100.1.3)
User ID – anything unique to identify your users (urn:oid:1.3.6.1.4.1.5923.1.1.1.10)
UID - login ID or username (urn:oid:0.9.2342.19200300.100.1.1)
If the naming format varies from the suggested default attributes, the below rules follow for naming conventions.
Case-sensitive
Must start with a letter or underscore
Cannot start with the letters "xml" or "XML" or "Xml" etc)
Accepted characters are letters, digits, hyphens, underscores, and periods
Element names cannot contain spaces
Provisioning Users with SAML SSO
When setting up SSO, Learning offers the option to auto-provision users upon logging in through a single sign-on. This creates the user with an account containing their name, email, and username. The user's username will be set to the value returned in the UID field. This does not update a user's standard or custom fields, bulk creates users or archives users.
This is able to be turned off meaning users must first be created in Learning before being able to sign in. To disable this feature please reach out to Support at support@lessonly.com.
Important Notes
Auto-provisioning users into Learning will throw an error if user's names contain special characters. For example: !@#$%^&*()+=[]{}?Users created through a successful single sign-on who need their name to be updated can only be updated in the customer's single sign-on application. Any change made manually in the Learning application, through an sFTP file sync, or on the backend of Learning will not be saved.
How to Set Up Google OAuth Single Sign-On
Seismic Learning supports OAuth through Google. Learning only needs the company's subdomain for this set-up.
Users are created the first time they log in to Learning using Google SSO.
Similar to SAML, this only creates the user's name and email address in Learning.
This does not update, bulk create, or archive users.
To set up Google SSO please reach out to Support at support@lessonly.com
Azure Active Directory
To integrate Azure AD with Learning, follow the steps listed in this documentation here.
After following the above documentation, send the following information to Learning Support at support@lessonly.com
Downloaded Certificate (Base64)
Sign Out / Log Out URL
SAML Entity ID
SAML Single Sign-On Service URL
Important Note: Azure uses the SMTP Address to authenticate with Learning. - SMTP Addresses are how a mail server such as Sendgrid, Google, and Office 365 identifies the user's name with an email address. If a user doesn't have an SMTP address, then Azure won't be able to check for the matching email address. The resolution would be to make sure the user has an account on the server.
Single Sign-On for ADFS
For all SSO set-ups through Active Directory Federation Services, please read this article: Single Sign-On for ADFS.
Expired Passwords with SSO Enabled
If a user has used both single sign-on and the manual sign-in process throughout their tenure, and then an action such as a Reset Password email is selected this immediately expires the user's manual password.
The next time the user tries to log in through single sign-on Learning auto-prompts them to create a new custom password. The user needs to set a new password, sign in manually, and then upon their next sign-in, they will be able to sign in through SSO.
For security purposes, this is mandatory to do if a user's manual password expires while subsequently using SSO. Passwords will not expire on their own.
Frequently Asked Questions
Q. What is the user experience when logging in with SSO?
A. The Learning login page has an additional button for SSO users. When users click that button, they are taken to the identity provider. When the identity provider authenticates the user, the user is returned to Learning and logged in.
Q. My Learning client has SSO enabled. What will happen if I enable standard login and a user logs in via this method rather than through SSO?
A. So long as the user's email address matches their identity in the database, their account will be recognized and the user will be able to manually log in. Should the user attempt to log in using a different email address, however, a new account will be created.
Q. Can Learning customers have multiple SSO options?
A. Yes, customers can enable two SSO schemes.
Q. Can Learning users bypass SSO?
A. No.
Q. My certificate is due to expire. What are the next steps for renewing it?
A. Send the Support team your new cert file. An agent will upload it, lickety-split!
Questions? Contact the Support team at support@lessonly.com