How Moodle SSO and identity integration works in a self-hosted site
Moodle single sign-on is delivered by authentication plugins that sit alongside the login page. Core ships LDAP, OAuth 2, Shibboleth and other auth plugins, and SAML 2.0 is commonly handled by the SAML2 Single sign on plugin (auth_saml2), which Catalyst IT maintains. Enabling the plugin is the easy part. The harder work is deciding how each person arriving from your identity provider is matched to a Moodle account, how identity attributes are mapped to Moodle profile fields, how roles and cohorts follow people as they change, and how accounts are suspended when someone leaves. Each of those decisions affects who can see grades, courses and personal data, so they belong in the design phase rather than after go-live. The work takes place inside your infrastructure. Your team, or a partner working in your cloud account, data center or private network, configures the Moodle site, connects it to your identity provider and tests the login paths against your real directory. The identity provider stays under your control, and the Moodle database, moodledata storage and any signing certificates remain in your environment. That matters for audit evidence too, because access logs, certificate ownership and change records should all point to systems you operate.
Account matching is the first decision to make. Moodle must know whether an incoming login belongs to an existing user, and the usual key is a stable identifier such as a directory object ID, an employee or student number, or an eduPerson-style attribute. Matching on email address is common but breaks when addresses change or are reused. Ask your identity team which attribute is immutable for each person, check how duplicate accounts from earlier manual or self-registered logins will be merged, and decide whether first login creates an account automatically or only links to a pre-provisioned one. Test with a sample of staff, students and external users, including people who already have a Moodle account.
Attribute mapping and role sync are where most integration defects appear. The identity provider might send department, year group, job title or group membership in different formats than Moodle expects, and some values will be missing for certain users. Map each attribute to a Moodle profile field or a cohort rule, and document the fallback when it is empty. Role assignment can come from the identity provider, from cohorts, or from enrolment plugins fed by an HR or student system, and these sources can conflict. Pick one system of record for each role, so a teacher's permission is not removed by one sync job while another grants it.
Deprovisioning is the risk most often left until last. An account that stays active after the person leaves exposes course content, submissions and personal data. Confirm how your identity provider signals departures, whether Moodle will suspend or delete accounts, and how long records are retained for grades and compliance. Ask the partner or your team to show a test where a disabled directory account is blocked at next login and its enrolments are removed or suspended on the agreed schedule. Plan for service accounts and web-services tokens separately, because they often sit outside normal login flows.
To prepare, collect the following before choosing a plugin: a list of identity provider attributes with sample values, the identifier used to match accounts, the source of each role and cohort, your leaver process and retention rules, and the Moodle version you will run. Confirm with your identity provider vendor which SAML or OIDC settings it supports and which metadata it will publish. Confirm with the plugin maintainer that its supported Moodle range includes your release before you commit to it. Those answers determine the build sequence and the testing effort.
Which Moodle components carry identity
Identity in Moodle is spread across several components rather than held in one place. Each one decides how a user is authenticated, what their profile looks like, and which courses and roles they receive, so a change in one can surface in another.
Core authentication plugins
Moodle core ships authentication plugins for manual accounts, email self-registration, external database, LDAP, LTI, OAuth 2, Shibboleth and web services. Only one or more of these are enabled per site, and each handles credentials and account creation differently. Confirm the exact settings, login flows and fallback behaviour for the version you will run before you choose a path.
SAML 2.0 through auth_saml2
SAML 2.0 single sign-on is commonly provided in Moodle by the auth_saml2 plugin maintained by Catalyst IT, which is not part of core. It creates users with field mapping configured in Moodle, so attribute names from the identity provider must line up with Moodle profile fields. Check the plugin's supported Moodle range against your target release before you commit to it.
The identity provider
The identity provider is the system of record for who a user is and which groups they belong to. Its claims, attribute names and group membership define what Moodle receives at login and during any sync. Agree with the identity team which attributes are authoritative, how they are named, and what happens when a user is removed from the directory.
User field mapping
Field mapping connects incoming identity attributes to Moodle user profile fields such as username, email, first name, surname and custom profile fields. A mismatch can create duplicate accounts, lock users out, or overwrite data that staff maintain by hand. Document each mapping, decide which side wins on conflict, and test with a sample of real account types before go-live.
Cohorts and enrolment methods
Cohorts are site-level or category-level groups of users that can be used to enrol them in courses through a cohort sync enrolment method. Other enrolment methods, such as manual, external database or LDAP-based enrolment, can assign roles on their own schedule. Map which group or attribute grants which course access, and make sure only one source is authoritative for each course to avoid conflicting role assignments.
Cron tasks that sync users
Several authentication and enrolment sync jobs run as scheduled Moodle tasks through cron. These tasks control when new accounts appear, when suspended users are disabled, and when cohort membership or enrolments change. Confirm task names, frequencies and run logs for your version, and make sure cron runs reliably, since a stalled cron leaves identity state out of date without an obvious error.
Which authentication method fits your identity provider
This table compares the Moodle authentication options for SSO and identity integration by the identity source you already run, the operational work each one adds, and who should own the decision. Read each row as a filter: start with the identity system your users already sign in to, then check the operating cost and the break-glass row before committing.
| Option | When it fits | Operational cost | Who owns the decision |
|---|---|---|---|
| LDAP | Users and groups live in an on-premises Active Directory or LDAP directory and the directory is reachable from the Moodle network | Directory exposure: a service account, TLS between Moodle and the directory, and firewall rules. Password checks depend on directory availability. | Identity team with the directory owner; Moodle administrator consulted on field mapping |
| OAuth 2 | Users sign in with a cloud identity provider such as an OpenID Connect or OAuth 2 service that you can register an application with | Client secret and redirect URI upkeep, token endpoint availability, and review of scopes and claims when the provider changes | Identity team, with the cloud identity administrator approving the app registration |
| Shibboleth | Students and staff access through a federation for academic or research access and attributes arrive from an institutional identity provider | Shibboleth service provider and attribute release configuration, federation metadata upkeep, and attribute mapping that must match the identity provider's release policy | Identity or federation owner at the institution, with Moodle administration handling attribute mapping |
| SAML2 plugin (auth_saml2) | Your identity provider speaks SAML 2.0 only and no OAuth 2 or LDAP path is available | Signing certificate and metadata renewal, plugin maintenance against each Moodle release, and vetting of the plugin's version support before upgrades | Identity team owns the IdP and certificates; platform team owns plugin compatibility and upgrades |
| Manual accounts kept as break-glass | A small set of named administrator accounts must still sign in if the identity provider or directory is down | Accounts need strong passwords or MFA, documented custody, periodic test logins, and removal of unused accounts after recovery | CISO or security lead approves; platform team maintains and tests the accounts |
| Enrolment and sync after sign-in | Cohorts, roles and deprovisioning must follow HR or student records, not only the login event | Scheduled sync jobs, attribute mapping reviews each term, and checks that suspended identities lose access | Data owner in HR or the student information system, with Moodle administrator running the sync |
| Choosing more than one method | Staff sign in with the corporate IdP while students or external learners use another source | Two login paths to test, support and document, with account-linking rules for users who appear in both sources | Platform owner, with each identity owner signing off on the users they supply |
How to build Moodle SSO in six steps
Six steps take a Moodle site from a confirmed release and server stack to a single sign-on connection that creates, updates and removes accounts as the identity contract requires. The sequence builds and tests the connection in a copy first, then cuts over with a rollback path. Each step closes with a check that the next step depends on.
Confirm the target release and stack
Before any configuration, the platform team confirms the Moodle release and its server stack against the release notes for that version. Check the 64-bit PHP version, the database engine and version, and the web server document root. Moodle 5.1 requires PHP 8.2 or later and moved the document root to the public directory, while Moodle 5.3 requires PHP 8.3 or later, PostgreSQL 17 or MariaDB 11.4 or a comparable listed engine, and an upgrade path from Moodle 4.4 or later. Confirm that the chosen authentication plugin also supports the target release. The step closes with a signed version and stack record from the platform owner.
Define the identity contract
Agree with the identity team what Moodle receives for every user before any connector is built. Specify the unique identifier Moodle uses to match an account across logins, choosing a stable value that does not change when an email address does. List the attributes Moodle needs, such as first name, last name, email and institutional ID, and the group or role claims that drive roles and cohorts. Record the source, format and expected values for each item, and ask the identity provider owner to confirm that these claims are released to Moodle. The step closes when both teams sign the contract and a sample user's attributes match it.
Configure the auth method in a copy
Select the authentication method that matches the identity provider and the institution's directory, such as the core OAuth 2, LDAP or Shibboleth plugins, or the SAML2 plugin (auth_saml2) for SAML 2.0. Build a non-production copy of the site, including its database and moodledata, and configure the connection there so test users never reach live accounts. Use a separate test application at the identity provider. Because auth_saml2 is a third-party plugin, review its listed compatibility, maintenance status and code before use. The step closes when a test user signs in through the identity provider and lands in a test account with the expected username.
Map attributes, roles and cohorts
Configure field mapping so each identity attribute populates the correct Moodle profile field, and map group or role claims to Moodle roles or cohorts. Decide whether role and cohort changes apply at each login, on a scheduled sync, or both, and whether removed claims remove membership or only add it. Check that no broad claim can grant administrator rights by accident. The step closes when a set of test users with varied claims shows the expected profile fields, roles and cohort memberships after a login and after a scheduled sync run.
Test first login and deprovisioning
Run a scripted test matrix in the copy covering a new user's first login, a returning user, a user whose email address changes, a user whose role claim is removed, and a user removed from the directory. Confirm that each account is created once, that identifiers match the contract, and that suspension or removal happens as the contract states. Verify that the scheduled sync task and cron run on the configured schedule. Record each result, fix defects in the copy and retest. The step closes when every case has a recorded pass and the identity and Moodle owners accept the results.
Cut over with a tested rollback path
Schedule the change in a window agreed with stakeholders and freeze configuration changes on the production site. Apply the verified settings, then open access to a small pilot group before opening it to all users. Keep the previous login method available, and document the revert steps, including a backup of the configuration and the switch back to the prior authentication plugin. Rehearse the rollback in the copy before the change. Monitor the first logins and the first sync cycle. The step closes when production logins and the first sync complete without unexplained account creation or suspension, and the rollback has been rehearsed.
What drives SSO effort and how to reduce it
This table lists the factors that change how long a Moodle SSO integration takes and what it costs to run, with a practical way to keep each one contained. Read each row as a decision: the driver on the left, why it adds work in the middle, and the design choice that limits it on the right. The main takeaway is that most avoidable effort comes from unclear identifiers, unagreed attribute contracts and multiple overlapping identity sources, so settle those before build starts.
| Driver | Why it adds effort | How to keep it down |
|---|---|---|
| User population and directory size | Large populations extend initial sync runtime, deduplication work and cutover testing, and make mistakes in matching more costly. | Scope the sync to the populations that need Moodle access, and run a staged pilot on a defined cohort before full import. |
| Number of identity providers and tenants | Each provider or tenant needs its own metadata, certificates, claim mapping, test cases and support path, and users can end up with duplicate accounts. | Use a single authoritative provider for Moodle logins, and treat any extra tenant as a separate scoped decision with its own sign-off. |
| Quality of attributes in the source directory | Missing, duplicated or inconsistently formatted email, name, student number or department fields force manual cleanup and custom rules in Moodle. | Audit the attributes Moodle will use before design, agree fixes with the directory owner, and make one stable identifier the account key. |
| Group and role rules | Rules that map directory groups to Moodle site roles, cohorts or course enrolments multiply quickly and are hard to test end to end. | Keep Moodle site roles few and documented, drive course access through enrolment or cohort sync from a short list of agreed group names. |
| Custom attribute mapping | Each non-standard field, transformation or fallback needs code or configuration, testing and documentation, and it can break when the directory schema changes. | Write an attribute contract listing each field, its source, format and owner, and limit mappings to that contract. |
| Plugin version compatibility with the target Moodle release | The SAML2 or other authentication plugin must support the Moodle release in use, and plugin changes can be needed at each major upgrade. | Check the plugin's listed Moodle support against the target release before selecting it, and budget for compatibility testing at every upgrade. |
| Number of environments | Development, test, staging and production each need identity provider configuration, certificates and test accounts, which multiplies setup and maintenance. | Keep environment differences to URLs and secrets, automate configuration, and run the same test script in every environment. |
| Compliance evidence requirements | Assessors may ask for records of access rules, provisioning and deprovisioning steps, change approvals and test results, which takes time to assemble if not captured as the work happens. | Record configuration decisions, test evidence and deprovisioning checks as part of delivery, and confirm the exact evidence list with your auditor before build. |
How account matching, provisioning and deprovisioning behave
The most consequential identity decision on a Moodle SSO project is how an incoming identity is matched to an existing Moodle account, because that match determines whether a returning learner keeps their enrolments and grades or ends up with a duplicate account. Moodle core ships several authentication plugins, including OAuth 2, LDAP, Shibboleth and the external database option, and each one handles matching differently. The SAML 2.0 route in this project is usually the SAML2 Single sign on plugin (auth_saml2), which creates users using field mapping configured in Moodle. Before go-live, the team should confirm, against the exact plugin version in use, which Moodle user field serves as the stable key (for example the username or an identifier mapped from the identity provider) and whether the plugin links to an existing account, creates a new one, or refuses to log in when no match is found.
On first login, the plugin typically creates or links the Moodle account and applies the attribute mapping at that moment. Scheduled sync is different: it reads the source directory on a timer and can create, update or suspend accounts without the user being present. These two paths do not always apply the same rules, so the team should test both. Create a set of test identities in the identity provider, including one with a changed surname, one with a changed email address and one whose username was reused, then record what Moodle does on first login and after the next scheduled run. Confirm which fields are overwritten on every sync and which are set only once, and check whether profile fields edited locally by users or administrators are reverted. Mapping decisions here should be signed off by the people who own the data, not left to the default plugin settings.
Deprovisioning is where most sites are unprepared. When a person leaves the source directory, Moodle does not automatically remove their work. Depending on the plugin and its settings, the account may be suspended, locked from SSO login, or left active with the password still valid for local login if an alternative authentication method exists. Suspension in Moodle blocks login but keeps the account, its enrolments, submissions and grade history intact, which is usually what records officers and academic governance need. Deletion removes the account and its personal data, which can break grade and audit trails and may conflict with retention rules. Decide the policy first: which accounts are suspended, after what delay, whether enrolments are removed or kept, and who approves permanent deletion. Ask the plugin vendor or maintainer to confirm each of these behaviours in writing, and test them on a staging site with a leaver account that holds graded work.
Enrolments and grades need their own check because they are tied to how the user leaves and how cohorts and roles are synced. If enrolments come from the directory through a sync or cohort process, removing a person from a group in the source may remove course access, which can cause grades to become hard to view even though the records still exist. The team should confirm what happens to a suspended user's course enrolments, gradebook entries and completion records, and whether teachers can still see them in reports. Plan for a periodic review of suspended accounts, a documented retention period set by your records policy and a rule for reactivating a returning person without creating a second account. Ask your Moodle partner to include these tests in the fixed-scope plan, so the offboarding policy is verified rather than assumed.
SSO differences by deployment model
On a single Moodle web server, the SSO design is the simplest. The browser talks to one PHP application, sessions live on one host, and the identity provider only needs to reach that one site. Most of the risk sits in configuration: the redirect URIs, the entity or client identifiers, and the attribute names that Moodle expects to receive. Because there is only one node, a misconfigured session or cookie setting shows up immediately in testing, which makes this model the easiest place to prove the attribute mapping and provisioning rules before anything else is added.
Points to design and check:
- Redirect and callback URLs: register the exact public hostname, including scheme and any path prefix, with the identity provider.
- Cookie domain and secure flags: confirm the cookie settings match the public HTTPS hostname so login does not loop.
- Attribute mapping: agree the username, email and role claims with the identity owner and test them with a sample account.
- Session lifetime: set the Moodle session timeout alongside the identity provider's session policy so users are not signed in twice or unexpectedly signed out.
- Local fallback: decide whether a break-glass administrator account remains available if the identity provider is unreachable.
Confirm with your identity team which protocol they support (OAuth 2, SAML 2.0, LDAP or Shibboleth) and which Moodle authentication plugin your version supports for it.
When several Moodle web nodes sit behind a load balancer, a login started on one node must be honored by all of them. The identity flow itself is unchanged, but the session state is not. If a user's requests land on different nodes and each node keeps its own session data, users are repeatedly sent back to the identity provider or lose their place mid-login. The design therefore depends on either sticky sessions at the load balancer or a shared session store that every node reads and writes, and on cookie settings that the load balancer and all nodes agree on.
Points to design and check:
- Session store: decide between sticky sessions and a shared store, and confirm the choice matches the high availability design for the rest of the platform.
- Load balancer headers: confirm the public scheme and host are forwarded correctly, since the redirect URIs depend on them.
- Cookie consistency: make sure every node issues the same cookie names, domain and secure attributes.
- Clock synchronization: signed assertions or tokens fail when nodes disagree on time, so confirm time sync across all nodes and the identity provider.
- Failover testing: remove one node during a login and confirm the user completes sign-in and keeps the session.
Ask your platform team how sessions and caches are shared across nodes today, because the SSO design should follow that decision rather than create a separate one.
In containerised or Kubernetes deployments, the SSO connection depends on secrets and certificates that are injected and rotated by the platform rather than edited on a server. Client secrets, signing keys and private certificate material usually arrive through a secret store or orchestrator object, and they change on a schedule set by someone other than the Moodle administrator. Pods are also replaced often, so anything written to the local filesystem during setup can disappear. The identity connection must therefore be configured from injected values, and the rotation process must update both the identity provider and Moodle without a login outage.
Points to design and check:
- Secret injection: keep client secrets and signing material out of images and out of the database where possible, and confirm how each is mounted into the container.
- Certificate rotation: agree who renews signing and metadata certificates, how the new certificate is published to the identity provider, and whether both old and new certificates are accepted during the change window.
- Ingress and TLS: confirm the ingress controller terminates TLS with the hostname registered at the identity provider and forwards the headers Moodle needs.
- Stateless pods: confirm any session or cache configuration does not depend on a single pod's local storage.
- Rollout behavior: test a rolling restart during an active login to see whether users are interrupted.
Confirm with your platform team which secret manager and certificate tooling the cluster uses and whether the identity provider can accept more than one active certificate.
On air-gapped or tightly restricted private networks, the identity provider, the metadata source and the directory may not be reachable from Moodle in the way a public SaaS integration assumes. SAML metadata, OAuth discovery documents, LDAP servers and certificate revocation checks all require network paths and sometimes outbound access that policy does not allow. Certificates must also be issued and renewed inside the environment, so the trust chain has to be understood before go-live. The design work is mostly about where each dependency lives, how its data is refreshed, and what happens when it is unavailable.
Points to design and check:
- Metadata and discovery: decide whether metadata is fetched live or imported as a file, and document how updates reach Moodle.
- Directory reachability: confirm LDAP or directory hosts are reachable from the Moodle network with the required ports and encryption.
- Offline certificates: agree how an internal certificate authority issues, distributes and renews signing and TLS certificates, and who holds the process.
- Time and name resolution: confirm internal DNS and time sources resolve the identity endpoints consistently.
- Failure mode: define what users see when the identity provider is down and whether a local administrator path is permitted by policy.
Confirm with your network and security teams which endpoints may be reached, how change approval works for certificate updates, and whether any dependency requires a diode or manual transfer.
Securing the identity path
A Moodle SSO deployment is only as strong as the path between the identity provider, the directory and the Moodle site. The cards below cover the transport, service accounts, administrator access, secrets and logging that connect those pieces, and what to verify in each before go-live.
TLS and certificates for SAML and OAuth 2
Every SAML and OAuth 2 endpoint on the Moodle side must be served over HTTPS with a certificate chain that the identity provider and browsers trust. Check certificate expiry dates, intermediate chains and hostname matching for the login and callback URLs, since a renewal failure will stop all federated sign-in. Confirm which metadata and signing certificates the identity provider expects and who owns their renewal.
LDAP bind account least privilege
Moodle's LDAP authentication and user sync use a bind account that should be read-only and scoped to the search bases that hold users and groups. Ask the directory team to confirm the account cannot write attributes or read unrelated subtrees, and document which attributes Moodle actually maps. Confirm that the bind password is rotated under a defined process and not shared across environments.
LDAPS for directory connections
Simple bind credentials must not travel in clear text, so the connection from Moodle to the directory should use LDAPS or StartTLS with certificate validation enabled. Confirm that the PHP LDAP extension and the directory's CA certificate are installed on every web node, including staging. Test a failed certificate deliberately so you know the login fails closed rather than falling back to an unencrypted connection.
MFA for Moodle administrator accounts
Administrator and manager accounts should authenticate through the identity provider with multi-factor authentication enforced there, not by Moodle password alone. Map privileged Moodle roles to specific identity provider groups so that granting site administrator rights requires a reviewed change. Confirm that a user removed from the directory loses administrator access on their next sign-in, not at some later manual cleanup.
Documented break-glass administrator
If the identity provider, certificate or directory fails, administrators need a way back into Moodle. Keep a manual authentication administrator account that is excluded from SSO, protected with a long unique password and stored in a sealed, audited location. Test the procedure on a schedule and record who may use it, when it was last exercised and how the account is disabled again.
Secret storage for client secrets and keys
OAuth 2 client secrets, SAML signing keys, LDAP bind passwords and database credentials should live in a secrets manager or restricted configuration, not in plugin settings exports, version control or shared documents. Confirm which values Moodle stores in its database and which can be supplied through the server environment or configuration file. Plan rotation for each secret and record its owner and expiry date.
Logging authentication events
Sign-in successes, failures, account creation, suspension and role changes made through SSO or LDAP should reach a central log that the security team can search. Verify which events the Moodle logs and the web server and identity provider logs capture, and align retention with your policy. Test that a failed login from a removed user appears in the central log within the window your monitoring requires.
How to test SSO and fail safely
The test plan for Moodle SSO should prove two things before go-live: that legitimate users reach the right account with the right roles, and that anything unexpected is refused. Build the test matrix around the identity provider and the authentication plugin you chose, whether that is OAuth 2, LDAP, Shibboleth or the SAML2 plugin (auth_saml2) maintained by Catalyst IT. Run each case against a staging Moodle that uses the same plugin version, field mapping and identity provider configuration as production, not a simplified copy. Record the expected result for each case in writing before testing starts, so the outcome is judged against the design rather than against whatever the site happens to do.
Cover the identity lifecycle first. Test first login for a brand-new user, which should create an account only if your provisioning rules allow it, and first login for a user who already exists in Moodle, which should match on the agreed unique identifier and not create a duplicate. Change a tracked attribute such as email, surname or department at the identity provider, sign in again, and confirm the Moodle profile updates only for the fields you mapped to update on login. Then suspend the identity at the provider and attempt sign-in, and confirm Moodle denies access. Check that a role or cohort change at the source is reflected after the next sync, and that removing the user from a cohort also removes the matching enrolment or cohort membership. Document the sync timing you observe, because it sets the window in which a departed user can still act.
Next, test the failure paths deliberately. Replace the signing certificate used by the SAML2 or OAuth 2 connection with an expired one in staging and confirm that sign-in fails with an error that does not expose configuration details, and that the failure is logged. Simulate a provider outage by blocking the identity provider endpoint or LDAP server, then confirm which accounts can still reach Moodle, which is normally none for SSO-only sites. Finally, confirm the forced return to manual login: identify the setting or recovery path that re-enables Moodle's built-in login for administrators, test it on staging, and agree in writing who holds the credentials and how that path is audited and disabled afterward. Confirm the exact behavior with the authentication plugin's documentation and your own configuration rather than assuming it.
Check the evidence in two places. In the Moodle logs (Site administration, Reports, Logs, and the security or authentication events your version records), look for successful and failed logins with timestamps, the authentication method used, and any account creation or update events. In the database, inspect the user table for the new or changed record, the auth field, the deleted and suspended flags, and the relevant rows in cohort and role assignment tables for the test accounts. Keep before and after snapshots of these rows for each case. Also check the web server access log and the identity provider's sign-in log so that a failed attempt can be traced end to end.
To confirm that Moodle fails closed for unknown users, use an identity that exists at the provider but has no matching Moodle account, and another that is valid but falls outside the allowed group or attribute filter. Both should be refused without creating an account, unless self-registration was deliberately enabled. Repeat the test with a manually created local account that is not meant to use SSO, and confirm that the authentication method restrictions behave as configured. Ask your implementation partner to include these negative tests, the evidence captured for each, and the rollback steps in the written acceptance criteria, so sign-off rests on verified results rather than on a successful demonstration.
What to monitor, back up and document after go-live
This table lists the operational signals, backups, retests and handover items that keep Moodle SSO working after launch. Read each row as a question your team must be able to answer on any given day, with the owner and evidence named. The main takeaway is that most SSO outages come from expired secrets, silent sync failures and upgrades that were never retested, so each of these needs a named owner before go-live.
| Area | What to watch or keep | Evidence to keep or check |
|---|---|---|
| Auth failures | Track failed logins, rejected assertions or tokens, and redirect errors per identity source, with alerts on sudden spikes | Log retention period, alert rules, and a sample of recent failure messages with their causes |
| Sync task runs | Confirm scheduled user and cohort sync tasks complete, and alert when a run fails or processes far fewer records than usual | Task history in Moodle, scheduler logs, and the last successful run time per sync |
| Certificate and secret expiry | Record expiry dates for SAML signing and encryption certificates, OAuth 2 client secrets and LDAP bind credentials, with reminders well before each date | Expiry register with owner, renewal date and the change record for the last rotation |
| Directory connection health | Check that LDAP or directory endpoints, bind accounts and failover hosts respond from the Moodle web and cron nodes | Connection test results, firewall rules in place, and the account lockout or password policy for the bind account |
| Backups including auth configuration | Back up the Moodle database with auth and identity plugin settings, OAuth 2 issuer configuration, field mappings and cohort rules, and test restore them | Backup schedule, restore test date, and a list of which secrets are stored outside the backup and how they are recovered |
| Upgrade and plugin retests | Repeat SSO login, logout, provisioning, deprovisioning and attribute tests after each minor or major Moodle release and each auth or identity plugin update | Signed-off test script, results for each identity path, and the release notes reviewed for auth changes |
| Runbook and attribute contract | Hand over a runbook for common failures and an attribute contract listing each identity attribute, its source field, Moodle field and owner | Versioned runbook, attribute contract approved by the identity owner, and named escalation contacts on both sides |
Moodle SSO questions buyers ask
What does Moodle SSO integration cost?
The cost depends mostly on what you connect to, how clean your directory data is, and how many environments need the same setup. A fixed-scope quote follows from a written scope that names the identity provider, the protocol (OAuth 2, LDAP, Shibboleth or SAML 2.0), the attributes to map, the provisioning and deprovisioning rules, and the environments to configure. DeployOpen does not publish a price list. The main cost drivers are: the identity contract and whether you already have an admin for it; directory quality, since duplicate or missing attributes add cleaning and mapping work; plugin choice, because core authentication plugins and the SAML2 plugin maintained by Catalyst IT carry different configuration and testing effort; and the number of environments, such as development, test and production. Ask any vendor to split one-time build work from recurring costs such as plugin updates, identity changes and support.
How long does Moodle SSO setup take?
Duration depends on scope, not on a fixed template. A single identity provider with clean attributes and one protocol is a smaller piece of work than several sources feeding cohorts and roles across multiple sites. The schedule usually turns on four things: how quickly your identity provider team can register the Moodle application and return metadata or client credentials; how many attributes need agreed definitions; how long testing with real test accounts takes; and whether deprovisioning rules need sign-off from HR or compliance before go-live. DeployOpen does not quote a duration without a written scope. Ask for a timeline that lists each dependency and who owns it.
Can our internal team set up Moodle SSO without a partner?
Yes, if your team owns three things: administrative control of the identity provider, Moodle administrator skills covering authentication, roles and cohorts, and a test environment where changes can be checked before production. Teams without one of these usually find the identity side or the testing side is the bottleneck. Protocol knowledge helps too. OAuth 2, LDAP, Shibboleth and SAML 2.0 each have different trust setup, certificate handling and attribute rules. A partner is most useful when the scope spans several identity sources, when the team lacks the identity or Moodle skills in-house, or when the rollout must be finished on a fixed date. Confirm your gaps honestly before choosing.
What do you need from our team for Moodle SSO?
The work needs decisions and access from several owners, so name them early. Typically you will need:
- Identity provider admin access to register the Moodle application, set redirect URIs, and export metadata or client details.
- Attribute owners who confirm the meaning and format of each field used for username, email, names, roles and cohorts.
- Test accounts covering staff, students, guests and edge cases such as name changes or shared mailboxes.
- Sign-off on the deprovisioning policy, including when access ends after leaving, suspension or contract end, and how courses and grades are retained.
- A Moodle administrator who can review authentication settings and role mappings.
Without these owners in place, timelines usually slip at the sign-off stage rather than in the build.
How do Moodle upgrades affect authentication plugins?
Authentication plugins can break during an upgrade because each Moodle release changes core APIs, PHP requirements and database versions. Core plugins such as LDAP, OAuth 2 and Shibboleth are maintained with core, but third-party plugins such as auth_saml2 depend on their own release cycle and must list support for your target version. Before any upgrade, check that the plugin supports the target release, confirm PHP and database versions, and test login, logout, provisioning and role sync on a staging copy. Note that from Moodle 5.1 the web server document root must point to the /public directory, which can affect callback URLs and certificate paths. Moodle 5.3 requires PHP 8.3 or later and sites must run Moodle 4.4 or later to upgrade, so older identity configurations may need rework. Ask your partner for a written compatibility check per plugin before each upgrade.
Does Moodle SSO handle user deprovisioning automatically?
It depends on how accounts are created and what the identity source sends. Some setups create accounts on first login, which does not remove them when a person leaves. Others sync from a directory or an external database on a schedule, and those can suspend accounts when a record disappears or is flagged. Confirm which mechanism you will use, how suspension differs from deletion, and whether any retained course history must be kept for records purposes. Test the full path with a leaver account in the test environment before production. Your identity and HR owners should approve the rules in writing.
Which SSO option should we pick for Moodle?
Choose based on your identity provider and existing directory, not on which protocol sounds most modern. LDAP suits organizations with an on-premises directory and clear group structures. OAuth 2 fits cloud identity providers that issue tokens for Moodle. Shibboleth is common in federated academic and public sector settings. SAML 2.0 through the auth_saml2 plugin, maintained by Catalyst IT, covers many enterprise providers, and its directory listing shows support for Moodle 2.7 through 5.1, so confirm support for your target release before selecting it. Ask the vendor or partner to document the trade-offs against your identity contract, attribute availability and audit needs.
How DeployOpen scopes, builds and hands over Moodle SSO
DeployOpen starts every Moodle SSO engagement with a written, fixed scope agreed before any configuration begins. The scope names the identity provider, the protocol (OAuth 2, LDAP, Shibboleth or SAML 2.0 through the auth_saml2 plugin), the attributes that must reach Moodle, the roles and cohorts that will be driven by identity data, and the sites or environments in scope. A scope that leaves the protocol or the attribute list open usually turns into an open-ended project, so DeployOpen asks the client to settle those points in writing first. Scope discussions also cover who owns the identity provider configuration on the vendor side, because Moodle changes depend on it. The build happens inside the client's own infrastructure: their cloud accounts, data center or isolated network, using their own staging and production Moodle instances. DeployOpen does not move identity data into a DeployOpen-hosted environment. Work follows a sequence that the team can review: a non-production Moodle instance connected to a test identity provider tenant, attribute mapping and login behavior confirmed, then provisioning and deprovisioning tested with a small set of test accounts, and only then a controlled change to production. Each stage has an entry and exit check agreed in the scope, so the client can see what has been proven and what remains open. At the end of the work, the client receives test evidence and a handover pack. Test evidence records the login flows exercised, including failed logins, expired sessions and a user who is removed at the identity provider, along with the attribute mappings and role or cohort rules as configured. The handover pack contains the configuration record, credentials and secrets locations (not the secrets themselves), runbook steps for adding an identity provider certificate or rotating a client secret, and known limits. DeployOpen prepares this evidence to support the client's own review and any compliance assessment they run. It does not issue audit reports, attestations or certifications, and independent auditors and certification bodies make those determinations. SSO rarely stays static after go-live. Moodle major and minor releases, plugin updates and identity provider changes can all affect authentication, so DeployOpen offers optional retainer support covering upgrade testing of the SSO path and ongoing fixes. Retainers are agreed separately from the fixed-scope build. DeployOpen is a Chainscore Labs company, and the implementation is delivered under that engagement model.
Before you request a quote: confirm which identity provider version and protocol your organization will use, who on your side can approve certificate or client secret changes, and whether a non-production identity tenant exists for testing.
