Aeion LMS + SAML / Google SSO
Learners never manage a separate LMS password. Aeion LMS runs on the platform identity layer, so district admins get real SAML 2.0 (SP metadata, IdP-metadata import, signed assertion handling, attribute mapping), Google / Microsoft / Okta social login, and SCIM 2.0 auto-provisioning — the same identity stack every Aeion module shares. On top of that, the LMS ships its own roster-sync connectors that pull sections, teachers, and students straight from Google Classroom, Canvas, and Clever into enrollments. What is live today and what is still being wired is labeled throughout.
Two Layers of Identity
Provisioning a learner into Aeion LMS happens on one of two layers. Knowing which is which keeps expectations honest.
Platform SSO — What Connects
`
LMS Roster Sync — What Connects
`
Setup
SSO and roster sync are configured separately.
Provisioning Flow — End-to-End
`
LTI 1.3 — Roadmap (real handshake, not yet multi-tenant)
Aeion LMS includes a working LTI 1.3 launch surface: an OIDC login-initiation endpoint (state + nonce), a launch endpoint that cryptographically verifies the platform's id_token against its JWKS with jose, and an Assignment & Grade Services (AGS) line-item endpoint for score passback. However, the platform issuer, JWKS URL, and audience are currently hardcoded to a Canvas demo configuration rather than read from per-tenant integration settings. The lms_integrations collection already carries the full lti1p3 config shape (issuer, client ID, deployment ID, JWKS/OIDC URLs, encrypted tool private key), but the launch route does not yet consume it, and roster/grade sync for the lti1p3 provider records an unsupported-sync no-op. Treat LTI 1.3 as a real handshake pinned to a demo config — the multi-tenant wiring is roadmap, not shipped default behavior.
What This Does Not Do (Yet)
Candid gaps, so nobody is surprised in a procurement review:
FAQ
The whole platform. SAML, Google/Microsoft/Okta social login, and SCIM live in Aeion's shared identity layer, so the same login provisions a user across LMS, CRM, Recruit, and the admin shell. There is no separate LMS-only identity stack to maintain.
Yes — SCIM 2.0 (RFC 7643/7644) is implemented with Users, Groups, and Bulk endpoints, tenant-scoped, with SCIM Groups mapping to tenant teams. An IdP that supports SCIM push can provision and deprovision accounts without a nightly export.
Not today. Clever is wired for *roster sync* (sections, teachers, students → enrollments) via an API key. Clever Instant Login (Clever-based SSO) is not implemented, and the Clever OAuth code-exchange path is a stub. Use SAML or Google social login for authentication and Clever for rostering.
The sync job completes with zero records and a machine-readable reason (`provider_sync_not_implemented`) instead of pretending it worked. That honesty was deliberate — an earlier build fabricated synced-record counts, and that behavior was removed.
The OIDC handshake, JWKS verification, and AGS score passback are real, but the platform endpoints are currently pinned to a Canvas demo config rather than read from per-tenant settings. Talk to your account team about timing before assuming LTI covers your tool.
One login for every learner, provisioned automatically.
Real SAML 2.0, SCIM auto-provisioning, and Google/Canvas/Clever roster sync — with honest labels on what's live and what's roadmap.