Setting up SAML single sign-on for your LMS with Entra ID, Okta or Google Workspace

Every separate login is another password to reset and another account to close when someone leaves. SAML single sign-on (SSO) connects your learning management system to your identity provider, so people sign in to training with their work account and access follows your directory. Here’s how SAML works, how setup goes with Microsoft Entra ID, Okta or Google Workspace, and what to check before go-live.

How SAML single sign-on works

SAML (Security Assertion Markup Language) 2.0 is an open standard for passing sign-in information between two systems that trust each other. The LMS never sees the person’s password: it sends them to your identity provider, which checks who they are, with any multi-factor authentication you require, and returns them with a signed statement.

Assertions are short-lived and name their audience (the SP’s entity ID). The SP rejects anything expired or meant for another application.

Why SSO is worth it for an LMS

• No extra passwords. People use their everyday account, and your MFA and access policies cover training too.
• Joiners get access quickly. Assign the LMS application to a group, and new staff in it can sign in on day one.
• Leavers lose access at the source. Disable someone in your directory and they can’t start a new LMS session. SAML controls sign-in, not the account, so archive the LMS account as part of offboarding too.

Just-in-time account creation

With just-in-time (JIT) provisioning, the LMS creates an account the first time someone signs in, from the assertion’s attributes, so there’s no user list to import. Put guardrails around it:

• Limit it to your own email domains, so a misconfigured application or guest account doesn’t create stray users.
• Give new accounts the lowest role, and grant administrator rights deliberately.
• Match people on a stable identifier where your IdP can send one, because email addresses change.

SP-initiated vs IdP-initiated sign-in

• SP-initiated: the person opens the LMS, which sends an authentication request to the IdP, and the IdP posts its response to the ACS URL. It works from bookmarks and email links, and is generally considered the safer flow because the response answers a request the LMS made.
• IdP-initiated: the person clicks the application’s tile in Microsoft My Apps, their Okta dashboard or the Google apps menu, and the IdP sends an unrequested response to the ACS URL.

You can offer both; test each.

Setting up SAML SSO, step by step

The sequence is much the same everywhere:

1. Plan the scope: who uses SSO, which groups get the application, which email domains are allowed, and which attribute identifies each person.
2. Create the connection in the LMS and note its entity ID and ACS URL.
3. Create a SAML application at your IdP with those values, choose the NameID format, and add email, first name and last name attributes.
4. Assign users or groups; unassigned people are usually turned away.
5. Give the LMS the IdP’s details: a metadata URL, a metadata file, or the IdP entity ID, sign-in URL and signing certificate.
6. Map the attributes to the names your IdP actually sends.
7. Test, then switch it on, and tell people what’s changing.

Provider notes

Your provider’s documentation has the exact screens. Worth knowing:

• Microsoft Entra ID: use a non-gallery enterprise application, not an app registration, which doesn’t offer SAML. Claim names are long URIs, so copy them exactly. The object ID makes a good stable identifier. For people without a mailbox the email claim may be empty; the user principal name can stand in if it’s a real address.
• Okta: create a SAML 2.0 app integration. You name the attribute statements yourself, so they must match the LMS mapping exactly, including case. Its internal user ID makes a stable identifier.
• Google Workspace: add a custom SAML app and download its metadata file. The app starts switched off, so turn it on for the right organisational units or groups. A typical setup identifies people by primary email, so plan for renamed and reused addresses.

Testing checklist

Before go-live, check these in a private browser window:

• An existing user signs in starting from the LMS, and again from the app tile.
• A new user on your domain gets an account with the right role.
• Someone not assigned to the application is refused.
• Someone outside your allowed domains is refused.
• Email, first name and last name arrive correctly.
• An administrator can still get in through the recovery path.

Common pitfalls

Clock skew

If the IdP’s and LMS’s clocks disagree by more than the LMS tolerates, good assertions are rejected as not yet valid or already expired. It mostly affects self-hosted identity servers, so keep their clocks synchronised.

Certificate rollover

IdP signing certificates expire, and if the LMS doesn’t trust the replacement, every sign-in fails at once. Diarise the expiry date. If your LMS can trust two certificates, add the new one there first, then activate it at the IdP; otherwise switch both sides together at a quiet time. Test straight away.

Attribute mapping

Attribute names are usually matched exactly: an LMS expecting email won’t accept Email. Check the identifier too. A transient NameID changes every session and an email address can change; a persistent NameID or an immutable ID attribute is stable. If people are matched by email, archive a leaver’s account before their address is reassigned.

Email domain mismatch

Directories often include people whose sign-in name isn’t their email address, contractors on other domains, and staff of acquired businesses still on old ones. If the LMS limits accounts to certain domains, they’re refused. List every domain before go-live.

How Acadenix does it

SAML SSO is on the Gold plan, with step-by-step guides for Entra ID, Okta and Google Workspace.

• Test, then activate. You save your IdP’s details as a draft, run Test configuration by signing in at your provider, and only then activate. A missing email claim is reported with the claim names your provider did send.
• Staged changes. A new certificate or tenant goes in as a configuration update, and the current configuration keeps working until you activate it.
• JIT within your domains. Someone without an account gets a learner account at first sign-in, only if their email is on your organisation’s registration domains, and you can switch this off. When someone who already has an Acadenix account first signs in through your IdP, Acadenix emails them a one-time code to confirm the link. This happens once per person.
• Both ways in. People start from your sign-in page, which can take them straight to your IdP or show a button, or from the tile in My Apps, Okta or Google.
• One connection, one organisation. A SAML connection doesn’t pass down to organisations beneath its owner, which matters for groups with many sites.
• A recovery path. If your IdP is down, administrators can still sign in with an emailed one-time code, and this can’t be switched off.

Alongside SAML, people can sign in with an emailed code or a Google, Microsoft or LinkedIn account. More on our security page.

Key takeaways

• Exchange entity IDs, the ACS URL and metadata, then map a stable identifier and verified email.
• Limit just-in-time accounts to your own domains and the lowest role.
• Test both sign-in flows, the refusals and the recovery path before go-live.
• Diarise certificate expiry and archive leavers’ LMS accounts.

Want to connect Acadenix to your identity provider? Compare plans on our pricing page, or talk to us about your setup.