LMS SSO lets your employees sign in to the training platform with the work account they already have, and the protocol on your IT ticket is the one the LMS supports: SAML 2.0 or OpenID Connect. The line most tickets leave out is what happens when someone leaves. SSO blocks a leaver’s sign-in once IT disables their work account, but it doesn’t touch their LMS account, and just-in-time provisioning can’t remove it at all. This guide gives you the protocol rule, the provisioning choice to settle first, the fields IT will ask for and the questions to put to any vendor.
Try Mini Course Generator free – and put it through the seven vendor questions in this guide, like every other LMS on your list.
Key Takeaways
- Microsoft’s rule for Entra ID: use OpenID Connect if the app supports it, and SAML if it doesn’t. The LMS vendor’s answer picks the protocol.
- SAML just-in-time (JIT) provisioning creates and updates accounts at sign-in but can’t delete or deactivate them. In the worked example below, that’s 96 active former-staff accounts after a year.
- SCIM lets the identity provider switch off an LMS account without the person signing in again. The LMS decides what an inactive account keeps, so ask.
- A SAML signing certificate from Entra ID lasts three years by default, and its expiry warnings go only to the admin who set it up unless you add more addresses.
SAML or OIDC: Let the LMS Decide, Then Tell IT
You don’t pick the protocol on its merits. The LMS supports one or both. Microsoft Entra ID (the service once called Azure AD) supports both, and Microsoft’s planning guide gives IT the rule in two lines: choose OpenID Connect if the application supports it, and choose SAML for existing applications that don’t.
Here’s what each one is, in the words IT will use.
- SAML 2.0 is an OASIS standard, an XML-based framework for exchanging security information between two parties. Your identity provider (IdP) vouches for the person with a signed assertion, and the LMS, the service provider (SP), accepts it.
- OpenID Connect (OIDC) is “a simple identity layer on top of the OAuth 2.0 protocol.” The identity provider hands the LMS an ID token, a JSON Web Token that says who signed in and can carry basic profile details.
Both give the LMS a signed statement about who the person is, so the difference you’ll feel is in setup. SAML swaps metadata files and certificates between the two systems. With OIDC, IT registers the LMS as an app, issues a client ID and enters the redirect address the vendor supplies.
SAML adds one more choice: where sign-in starts. In an SP-initiated flow, the person opens the LMS first, from a bookmark or a link in an assignment email, and gets sent to the company sign-in page. The OASIS technical overview calls this the more common scenario. In an IdP-initiated flow, the person is already signed in to the company app portal and clicks the LMS tile.
If your courses go out by email, SP-initiated has to work. If people start their day in an app portal, ask for IdP-initiated too.
Put on the ticket: the protocol the vendor confirms, and which sign-in starting points must work.
What Happens to the LMS Account When Someone Leaves
SSO answers one question: can this person sign in right now? It doesn’t decide whether their LMS account should still exist. That’s provisioning, and an LMS handles it in one of three ways.
| Manual | Just-in-time (SAML JIT) | SCIM | |
|---|---|---|---|
| Account created | An admin adds it or uploads a spreadsheet | At first sign-in, from details in the SAML assertion | By the identity provider, before first sign-in |
| Name or department changes | By hand | At the person’s next sign-in | On the identity provider’s next sync |
| Someone leaves | An admin removes the account | Nothing happens | The identity provider deactivates or deletes it |
| Extra setup for IT | None | A setting on the SAML connection | A second connection with its own credential |
Just-in-time: accounts appear but never disappear
JIT reads the details your identity provider sends at sign-in and creates or updates the LMS account from them. Microsoft’s guidance for app vendors states the limit in one sentence: SAML JIT “is useful for creating and updating users, but it can’t delete or deactivate the users in the application.”
So a leaver whose work account is disabled can’t get back in through SSO, and their LMS account stays active anyway. It can keep counting toward your user total, keep getting assignment reminders and keep showing as overdue on a compliance report. It stays that way until an admin removes it.
SCIM: the identity provider keeps the LMS in step
SCIM, the System for Cross-domain Identity Management, is a second connection, separate from sign-in. It needs its own credential. The protocol standard, RFC 7644, doesn’t define an authentication scheme of its own, so IT sets one up apart from SSO. Once it runs, the identity provider creates, updates and switches off LMS accounts on its sync schedule, whether or not the person ever signs in again.
In Microsoft Entra ID, a user who’s disabled, or removed from the LMS app’s assignment, is disabled in the LMS on the next sync cycle. For a SCIM app, that means setting the account’s active value to false. A user deleted in Entra is permanently deleted 30 days later, and the LMS gets a delete request then, if deletes are switched on for the connection. Okta takes the same first step: deprovisioning a user sets active=false in the connected app.
One line in the standard belongs on your vendor list. RFC 7643 defines active as the user’s administrative status and says its definitive meaning “is determined by the service provider.” In plain terms, the LMS decides what an inactive account keeps: completions and certificates in reports, and a place in your license count or not.
A worked example: one leaver, three models
This is an example, so swap in your own numbers. A 600-person company runs Microsoft Entra ID, and eight people leave each month. IT disables each leaver’s work account on their last day.
| What happens | Manual | SAML JIT | SCIM |
|---|---|---|---|
| Last day, work account disabled | No SSO sign-in, LMS account active | No SSO sign-in, LMS account active | No SSO sign-in, LMS account active |
| Next sync cycle | No change | No change | LMS account set to inactive |
| Work account deleted | No change | No change | LMS account deleted 30 days later, if deletes are on |
| Leaver accounts still active after 12 months, no cleanup | 8 × 12 = 96 | 8 × 12 = 96 | 0 |
Under manual or JIT, those 96 accounts are a job, not a setting. Give the job an owner and a day in the offboarding checklist, and write both into your LMS implementation plan. Under SCIM, the job moves to the identity provider, and yours becomes checking that the sync keeps running.
Decide before you file: SCIM if the LMS offers it on your plan and IT runs a provisioning service. Otherwise, JIT or manual, plus the name of the person who removes leavers.
SSO Signs People In. It Doesn’t Move Training Records.
Sign-in, accounts and training records are three separate connections, even though a learning management system sits in the middle of all three. Mixing them up is how a request for “SSO with Workday” reaches a vendor when what you wanted was completions flowing back to HR.
OpenID Connect exists to verify who the user is and pass basic profile information, and a SAML assertion carries statements about the person signing in. Neither carries a course completion.
- Sign-in (SSO): SAML or OIDC between your identity provider and the LMS.
- Accounts (provisioning): SCIM from the identity provider to the LMS. The identity provider can itself be fed from HR, since Microsoft Entra ID supports inbound provisioning from Workday and SAP SuccessFactors. With both links in place, the termination HR records can switch off the LMS account without anyone opening the LMS. Connecting the LMS to your HRIS maps the HR fields that should come across with the account.
- Records (integration): an LMS API, webhooks or a connector that sends completions, certificates and due dates to your HRIS or a reporting tool.
When a request names your HRIS, say which of the three you mean. The records side, and the order to connect systems in, is covered in which systems to connect first.
The LMS SSO Ticket: What to Send and What IT Will Ask For
A SAML connection is two systems swapping configuration. The SAML technical overview describes metadata as the way the two sides share identifiers, supported attributes and the keys used for signing. Microsoft’s walkthrough for connecting one LMS to Entra ID shows the whole exchange. IT enters three values from the vendor, maps the user identifier, downloads the Federation Metadata XML and sends it to the vendor with the sign-in addresses.
A complete ticket gets that done without a string of follow-up emails.
From the LMS vendor, before you file
| Field | Also called | What it is |
|---|---|---|
| Entity ID | Identifier, Audience URI | The LMS’s unique name in the connection |
| ACS URL | Reply URL | Where the identity provider sends the signed assertion |
| Sign-on URL | Login URL | Where SP-initiated sign-in starts |
| Supported flows | SP-initiated, IdP-initiated | Which starting points work |
| Unique identifier | NameID | The value the LMS matches to an existing account, usually email |
| Required attributes | Claims | First name, last name and email, plus anything used for groups |
| OIDC only | Redirect URI | Where the person returns after sign-in (IT issues the client ID) |
From you, because nobody else knows it
- Who’s in scope. Name the groups, and make sure the people are direct members. Entra ID doesn’t read users inside nested groups, for provisioning or for group-based SSO access.
- What today’s LMS accounts use to sign in. If existing accounts use email and IT sends the user principal name, sign-ins won’t match. Microsoft’s LMS walkthrough flags this exact case: Entra sends the user principal name by default, the app expects email, so IT maps the email attribute instead.
- Which attribute places people. Department, location or manager, if you want courses assigned by group.
- The provisioning model. SCIM, JIT or manual, and who removes leavers.
- Who gets certificate warnings. A distribution list, not one admin.
Ticket text you can paste
Request: single sign-on for [LMS name] for [group names]. Go-live [date], with a pilot of [number] people first.
Protocol: [SAML 2.0 / OIDC], confirmed by the vendor. Sign-in must work from [the LMS link / the app portal / both].
Vendor values attached: Entity ID, ACS URL and sign-on URL (SAML), or redirect URI (OIDC).
Identifier: email, so existing LMS accounts match. In Entra ID, map it to the email attribute, not the user principal name.
Attributes: first name, last name, email, [department].
Provisioning: [SCIM, with the credential from the vendor / JIT / manual]. Leavers removed by [identity provider / name] within [number] days of their last day.
Certificate expiry notices to: [distribution list].
Please send back: the federation metadata XML and the certificate expiry date.
What Breaks After Go-Live, and Who Hears About It
LMS SSO that works on launch day can stop on a date nobody wrote down. Three failures show up months later, and none of them warns the training team first. The clocks below are Microsoft Entra ID’s defaults. If IT runs Okta or another identity provider, ask for its certificate lifetime and what it does with a provisioning job that keeps failing, because the numbers may differ.
| What breaks | Microsoft Entra ID default | What the training team sees | Ask |
|---|---|---|---|
| The SAML signing certificate expires | Valid three years; warnings 60, 30 and 7 days before expiry, sent only to the admin who added the app | Nothing, until sign-in might fail | Does the LMS read a new certificate from our metadata? |
| The SCIM provisioning job keeps failing | Job quarantined, slowed to once a day, disabled after four weeks | Nothing: sign-in still works, and leavers stop being removed | Who gets the provisioning alert email? |
| The identifier changes | No matching account found, so a new one is created | A second account, with completion history left on the old one | How does the LMS merge or update accounts? |
The certificate. If the admin who set up the app has moved on, nobody hears the warnings. Microsoft’s own note is blunt: if the app isn’t updated with the new certificate, authentication to it might fail. Add up to five addresses to the notice list.
A vendor can make the rollover a non-event. Microsoft advises app vendors to check metadata at least every 24 hours and to hold two certificates at once, so the switch causes no downtime.
The sync. A SCIM job can stall because its admin credential is no longer valid, and nothing changes on the sign-in side. Nobody complains, so leavers keep active LMS accounts until someone looks.
The identifier. Someone changes their surname and their email changes with it, or IT changes which value it sends. If the LMS matches on email, the new value won’t find the old account, and Microsoft’s provisioning service opens a fresh one. Ask the vendor how accounts get merged before anyone changes the identifier.
Put two names on the calendar: who renews the certificate, and who watches the provisioning job. Microsoft’s planning guide assigns certificate rollover to infrastructure admins, so the first name is usually someone in IT.
Questions for Any LMS Vendor Before You Assume SSO Is Included
Vendors don’t always put SSO and provisioning on the same tier, and a features page doesn’t always say which is where. Continu, as of September 2026, includes SAML 2.0 SSO on its entry Growth tier and publishes automated SCIM provisioning without naming the tier that includes it. Get these answers on the quote, not from a slide.
- Which plan on this quote includes SSO, and which includes provisioning?
- SAML 2.0, OpenID Connect or both? SP-initiated, IdP-initiated or both?
- Is provisioning SCIM, JIT or manual? If it’s SCIM, does removing someone deactivate the account or delete it?
- What does an inactive account keep: completions, certificates, report history? Does it still count toward our user total?
- Once SSO is on, can anyone still sign in another way, such as a password set up before SSO?
- Does the LMS read a new signing certificate from our metadata, or does someone upload it by hand?
- Which attributes can assign groups or courses at sign-in?
Add them to your LMS demo questions, and to the SSO rows of your LMS requirements checklist. If IT’s review goes past sign-in, the LMS security checklist has the questions for the rest of the vendor review, and who hosts the LMS and who patches it covers the hosting side.
File the Ticket With the Removal Line Filled In
Get the protocol, the sign-in flows and the SAML values from the vendor before you write to IT. Then decide how leavers come out: SCIM if it’s on your plan, or a named person and a day in the offboarding checklist if it isn’t. File the ticket with that line filled in, plus the certificate notice list. A ticket without the removal line gets you SSO and a growing list of former staff with active accounts.
Mini Course Generator is our product. SSO for learners is on its Custom plan, and it doesn’t offer SCIM provisioning, so on MCG removing a leaver is a step in your own offboarding checklist. Once sign-in is settled and the courses are the next job, see what an AI LMS drafts and tracks for a training team.
Frequently Asked Questions
Is SSO the same as SCIM?
No. SSO signs a person in. SCIM creates, updates and deactivates their account. An LMS can have SSO with no SCIM, and then accounts come from just-in-time provisioning or from an admin.
If IT disables someone’s work account, are they removed from the LMS?
No. They can’t sign in through SSO anymore, but their LMS account is deactivated only by SCIM or by an admin. Check one more door: if accounts had passwords before SSO was switched on, ask the vendor whether those passwords still work.
Does every SSO LMS support SCIM?
No. Some LMS vendors publish SAML SSO with no provisioning, and some put provisioning on a different tier from SSO. Ask which plan on your quote includes each one.
Our LMS only supports SAML. Is that a problem for IT?
No. Microsoft’s guidance for Entra ID is to choose OpenID Connect where an app supports it and SAML for apps that don’t, so a SAML-only LMS is a standard setup. Ask the vendor for the SAML values and the supported flows up front.
Who owns SSO for the LMS after launch?
Two people, usually on two different teams. Microsoft’s planning guide puts certificate rollover with infrastructure admins, so the certificate owner sits in IT. Access and, without SCIM, leaver removal sit with the training team. Write both names into the ticket, because each failure lands on a different desk.
Sources
- OASIS: SAML 2.0 Technical Overview
- OpenID: OpenID Connect Core 1.0
- IETF: RFC 7644, SCIM Protocol
- IETF: RFC 7643, SCIM Core Schema
- Microsoft Learn: Enable automatic user provisioning for multitenant applications
- Microsoft Learn: Plan a single sign-on deployment
- Microsoft Learn: How application provisioning works in Microsoft Entra ID
- Microsoft Learn: What is automated app user provisioning
- Microsoft Learn: Manage federation certificates for federated single sign-on
- Microsoft Learn: Configure LMS and Education Management System Leaf for single sign-on with Microsoft Entra ID
- Okta: Understanding SCIM
- Continu pricing and security pages
