LMS requirements checklist

Moodle core ships a set of authentication plugins that cover most identity patterns without a third-party add-on. The list includes manual accounts, email self-registration, an external database, LDAP, LTI, OAuth 2, Shibboleth and web services. Each plugin answers a different question: who creates the account, where the password is checked and how the learner's attributes reach the site.

• Directory sign-in: The LDAP plugin checks credentials against an existing directory, so staff and students use their usual passwords.
• Federated sign-in: Shibboleth and OAuth 2 suit campus or enterprise single sign-on, but the exact identity provider setup must be tested against your own tenant.
• External database: This plugin reads accounts from a database you control, which can serve as a bridge to an HR or student system.
• Web services: Moodle's web service layer lets an outside system create or update users and enrollments, which is useful for scheduled or event-driven provisioning.
• Self-registration: Email self-registration is rarely acceptable for regulated training, where accounts should come from a source of record.

Confirm plugin maturity and support status with Moodle HQ, the plugin maintainer or the community before relying on any of them, and confirm which plugins your Moodle version still supports.

Open edX handles third-party sign-in through its own third-party authentication (TPA) layer. The documented options are OAuth2 providers, SAML 2.0, Shibboleth and LTI. Older provisional support exists for CAS and SSL client certificates. The OAuth2 defaults include Google, Facebook, LinkedIn and Azure Active Directory, while other providers require configuration. Because the set of supported identity providers is narrower and more specific than Moodle's, the identity design has to be confirmed earlier in the project.

• SAML 2.0 and Shibboleth: These are the usual routes for corporate or campus single sign-on, and they need a tested metadata exchange with your identity provider.
• OAuth2 providers: Azure Active Directory and Google are documented defaults, so confirm whether your tenant or domain setup matches them.
• Provisional protocols: CAS and SSL client certificates are older provisional options, so treat them as items to validate rather than assumed capabilities.
• Account creation: Confirm whether first sign-in creates an account automatically and which attributes are mapped at that point.
• Enrollment sources: Decide whether enrollments come from an HR or student system through an API, a file import or an LTI launch, and who owns that integration.

Confirm the exact provider configuration, the attributes passed at login and how the release you plan to run handles TPA changes with the Open edX community or your implementation partner.

Single sign-on is the first requirement most organizations raise, and it looks similar on both platforms but fails in different places. The identity provider remains the source of truth for passwords, multi-factor policy and account status, while the LMS decides which role a person holds inside a course. Plan the boundary between those two systems before any configuration starts.

• Identity provider ownership: Confirm who operates the identity provider, who can change its claims and how changes reach the LMS.
• Multi-factor policy: Confirm whether the identity provider enforces multi-factor authentication for learners, staff and administrators, and whether any local login path bypasses it.
• Attribute mapping: Agree which attributes (such as a unique identifier, email and organizational unit) become the LMS account key, because changing that key later is disruptive.
• Local administrator access: Keep a documented break-glass path for administrators that does not depend on the identity provider being available.
• Session and timeout rules: Confirm session lengths for shared or kiosk devices, since training records may depend on who was signed in.

Ask your identity team to test sign-in with a set of pilot accounts, including expired and disabled accounts, before the first learner is onboarded.

Just-in-time account creation and role mapping decide whether access follows a person's job or lingers after they leave. A learner who creates an account at first sign-in is convenient, but the LMS still needs rules for roles, course assignment and removal. Deprovisioning is where many training platforms fail an audit, because former employees or contractors may keep access to course content or completion records.

• Just-in-time creation: Decide which identity groups may create accounts on first login and which must be pre-provisioned by an administrator.
• Role mapping: Map directory groups to LMS roles (learner, instructor, manager, administrator) in a written table that the business owner approves.
• Deprovisioning timing: Agree how quickly a disabled identity-provider account stops working in the LMS and whether completion records are retained after removal.
• Orphaned accounts: Run a scheduled reconciliation between the source system and the LMS to find accounts that no longer match an active person.
• Audit logging: Confirm that account creation, role changes and deletions are logged in a form your auditors can read.

Illustrative example: a contractor leaves on a Friday, and the identity provider disables the account that day. Ask the partner to show, in a test environment, whether the LMS login and any active enrollments are blocked and how the record is kept.

Enrollment links the people in the identity source to the courses they must complete. The two common patterns are a push, where the HR or student system sends changes to the LMS as they occur, and a pull, where the LMS or an integration job reads the source on a schedule. Each pattern has different failure modes, so the choice should follow from how often roles change and how quickly training must be assigned.

• Push integration: Changes arrive as events or API calls, which suits new hires and role changes, but requires monitoring for failed deliveries.
• Pull integration: A scheduled job reads a source extract, which is easier to reconcile but delays assignment until the next run.
• Source of record: Confirm which system owns job role, department, location and course entitlements, so the LMS does not hold a competing version.
• Retries and error handling: Agree how failed records are reported to an administrator and who fixes them.
• Platform-specific routes: On Moodle, confirm which web services or external database plugin will carry enrollments. On Open edX, confirm whether enrollments will use an API, a provider integration or an LTI launch.

Ask the partner to document each enrollment route, its owner and its test cases, and to confirm the support status of any plugin before it enters the production design.