Open source SSO for education

Open source SSO for education: why campus identity is different

An IT director at a university usually inherits a login problem that grows every term: thousands of students arrive, change programs, graduate or leave, while staff, contractors, visiting researchers and dozens of applications all depend on one set of credentials. The function is campus single sign-on over SAML and OIDC, run on a self-hosted identity provider, and the right platform depends on three things: how the institution federates with research and education identity networks, how deeply the learning management system must integrate, and how much identity engineering the in-house team can sustain. DeployOpen implements that stack inside the institution's own cloud account or data center, so student records and authentication logs stay under the institution's control.

The account lifecycle on campus is driven by academic cohorts rather than by individual hiring events. Admissions feeds create accounts in large batches before a term, enrollment changes move students between programs and courses, and graduation or withdrawal removes access on a schedule that the registrar sets. Teams should confirm which system is the authoritative source for each population (student information system, HR system, or a sponsored guest process), how a student record that changes mid-term propagates to the LMS and other applications, and who may approve exceptions for alumni and contractors. Under the FERPA regulations in 34 CFR Part 99, an outside contractor may see education records only as a school official under the institution's direct control, so the integrator's administrative access to the identity provider needs the same scrutiny as any other school official.

During enrollment peaks, the identity provider becomes a single point of failure. When a large intake logs in to the LMS, email and registration tools within the same hour, a stalled login service blocks every application at once, and the help desk absorbs the account recovery volume that follows. Plan for a clustered Keycloak or authentik deployment with a tested database failover path, load testing against the peak your registrar expects, and self-service account recovery that does not depend on a single help desk queue. The Keycloak high availability documentation requires a synchronously replicated database for its supported designs, so confirm the database platform and its replication model with your team before committing to a design. Ask any implementation partner to show the failover and recovery runbook they will deliver, and to explain how it was tested.

Which education rules shape the SSO build

This table maps the US education and financial aid rules most likely to affect a campus SSO build to the concrete design choices each one implies. Read each row as a question for counsel and the compliance lead: confirm which rules apply to your institution, then use the build column to decide what the identity provider must record and enforce.

Rule	What it asks for	What it means for the SSO build
FERPA school official and access control (34 CFR 99.31)	Vendors and contractors may see education records only as school officials under direct institutional control, and access must be limited to records with a legitimate educational interest	Use named accounts for staff, contractors and service providers, scope group membership to roles, and document which applications sit under the institution's control
FERPA disclosure record (34 CFR 99.32)	The institution keeps a record of each request and disclosure of personally identifiable information, kept as long as the records are kept	Retain login and application-access events long enough to correlate with disclosure logs, and confirm with the registrar what the disclosure record must contain
FERPA inspection window (34 CFR 99.10)	Records must be made available to a parent or eligible student within a reasonable period and not more than 45 days after the request	Make sure account and identity attributes can be located and exported quickly for a request, including linked accounts and alumni or former student identities
GLBA Safeguards MFA (16 CFR 314.4 and FSA GENERAL-23-09)	Title IV institutions agree in their Program Participation Agreements to follow the Safeguards Rule, which requires MFA for anyone accessing any information system	Enforce MFA for staff and faculty with access to student financial aid and finance systems, and confirm with compliance whether student-facing access is in scope
GLBA monitoring and logging (16 CFR 314.4)	Activity of authorized users must be monitored and logged, and a written information security program must exist	Log successful and failed authentications, MFA enrollment changes and admin actions in the identity provider, and forward them to the institution's log platform
Notification of events (16 CFR 314.4(j))	Notice to the FTC within 30 days of discovering an event affecting at least 500 consumers	Keep identity logs complete and time-synchronized so the institution can scope an incident quickly enough to meet the deadline
COPPA for children under 13 (16 CFR 312.10)	Operators collecting personal information from children under 13 keep data only as long as needed and maintain a written retention policy	Apply only where the institution serves children under 13, such as K-12 or lab schools; set account deletion timeframes and avoid collecting unnecessary attributes

Which open-source identity platform fits a campus

Keycloak is the broadest option on the list and is the one most campuses evaluate first. It is licensed under Apache-2.0, supports OpenID Connect, OAuth 2.0 and SAML 2.0, and can federate LDAP and Active Directory user stores, which matters when student and staff records sit in different directories. The Apache license permits internal modification and redistribution without copyleft obligations, so IT teams can extend login flows or themes without releasing their changes. Institutions that want a supported distribution can use the Red Hat build of Keycloak, which is based on the open source project and replaces Red Hat Single Sign-On.

SAML federation: Keycloak can act as a service provider to a national research and education federation and as an identity provider to LMS and library applications, but the trust metadata, attribute release and signing settings must be tested against your federation operator's requirements.
Directory fit: LDAP and Active Directory federation suit campuses with a central student information system feeding a directory.
Operating load: Expect a dedicated platform team to own upgrades, database tuning and high availability, since Keycloak documents clustering that needs a synchronously replicated database.
Upgrade cadence: The project plans four minor releases a year, so ask how your team will test each one before it reaches production during enrollment periods.

Confirm federation interoperability with your federation operator in a test realm before committing to a design.

How SAML federation with a research and education network works

The campus identity provider only trusts a federation it has explicitly joined. In a SAML federation, the institution's identity provider (IdP) publishes its metadata, which carries its entity ID, its signing certificate and its single sign-on endpoints. Service providers consume that metadata to learn where to send users and which certificate signs their assertions. In the other direction, the institution imports the federation's metadata to learn which service providers are members and which certificates they use. Keycloak's SAML 2.0 support covers the IdP role, so the practical work is loading the federation metadata into the realm, pinning the signing certificates the federation publishes, and setting up a process to renew them before they expire. Before go-live, confirm with the federation operator which metadata feed and trust roots apply to your institution and which signing certificate rotation process it follows.

Attribute release is a decision the institution makes for each service provider, not a default the federation makes for it. When a student launches a library database or a learning tool, the IdP builds an assertion containing only the attributes the institution chooses to release to that service. Each release rule should map to a documented need, such as a role or affiliation value that the service requires, and should avoid sending identifiers the service does not use. Under FERPA (34 CFR Part 99), a school official may access only the education records in which it has a legitimate educational interest, and the institution must use reasonable access controls to enforce that limit. Attribute release is one of those controls, so each release rule should be reviewed by the registrar or privacy office, not only by the identity team. Illustrative example: a course-tool vendor may need a course enrollment value but not a date of birth or a student ID number.

How a campus SSO rollout moves from pilot to term start

The sequence turns a set of student and staff applications into one tested login path, with each phase producing a signed-off artifact so the cutover before term start is a planned change rather than a leap of faith. Timing depends on the number of applications, the directories involved and how much change control the institution requires.

Inventory applications and their login protocols
DeployOpen works with the registrar, IT service owners and the teams that run the LMS, library, finance and housing systems to list every application that needs login, the protocol each one supports (SAML 2.0, OpenID Connect, LDAP or none), and who owns it. Applications with no SSO support are flagged early so they can be wrapped, proxied or scheduled for replacement. The output is an application register with owner, protocol, user population and a go or no-go status for each system. The phase is complete when the institution's owners have reviewed and signed the register.
Design directory and student information system sync
The team maps where identities originate, usually the student information system for students and the HR system or staff directory for employees, and designs how accounts are created, updated and disabled from those sources. It decides which directory Keycloak or the chosen identity provider federates with (for example, LDAP or Active Directory user federation), how student identifiers are matched, and how withdrawn or graduated students lose access. The output is a written identity data flow and attribute map that registrar and privacy staff approve. Confirm the exact attributes each federation partner expects before the design is final.
Build the identity provider and run a faculty pilot
DeployOpen builds the identity provider in the institution's own environment, configures the agreed protocols, and connects it to the first directories. A single faculty group, with a small set of applications, signs in through the new path for a defined period while the team collects login failures, session behavior and help desk questions. Problems found here are fixed in the configuration and tested again. The output is a pilot report listing defects, fixes and the criteria the group used to accept the design for wider use.
Integrate Moodle and configure its authentication
The LMS is connected over the agreed protocol, typically SAML 2.0 through the SAML2 Single sign on plugin or OAuth 2 and LTI where the LMS is the consumer of an external tool. The team confirms which Moodle authentication plugins remain enabled, such as manual or LDAP accounts for break-glass use, and disables the rest. On Moodle 5.1 and later, the web server document root must point to the new /public directory rather than the main Moodle folder, or the site may show directory listings or errors. The output is a tested login flow for students and staff, with the Moodle version, plugin list and web server configuration recorded.
Set up self-service recovery and staff MFA enrollment
The team configures self-service account recovery, such as password reset through verified contact methods, and defines how identity is proven when a student cannot use those channels. Staff MFA enrollment is rolled out in groups, with help desk scripts and a fallback path for lost devices. Recovery steps are tested with the help desk so that verification is consistent. The output is a documented recovery procedure, an enrollment schedule by group, and test records showing that recovery and enrollment work end to end.
Load test against enrollment peaks
Before cutover, the team tests the identity provider and its database at the login volumes the institution expects during enrollment, add-drop and the first week of term, using the peak timetable supplied by the registrar. Tests cover concurrent logins, token issuance, directory sync jobs and LMS sign-in bursts, and they check how the high availability design behaves when one node fails. The database must support the replication model the chosen high availability design needs. The output is a load test report with measured limits, the bottlenecks found and the scaling changes made. Ask the partner to show the test plan before it runs.
Cut over before term start
The team moves production traffic to the new identity provider during an agreed window, keeps the previous login path available for rollback, and watches sign-in success rates, error logs and help desk volume during the first sessions. Applications are switched in the order set in the register, with the lowest-risk systems first. The output is a cutover record showing the time of each switch, the checks passed, any rollback decisions and the open issues carried forward. The cutover is complete when the business owners confirm that their applications work for real users.
Hand over runbooks and operating responsibilities
DeployOpen documents the configuration, the upgrade procedure, backup and restore steps, monitoring and alerting, and the escalation path, then transfers operating responsibility to the institution's identity or platform team. Staff are trained on the administration console and on the recovery and enrollment procedures. The handover is complete when the institution's team has run one planned operational task, such as a backup restore test or a configuration change, without assistance. Ongoing support, upgrades and testing can be arranged separately as a retainer.

Deployment patterns for peak enrollment and high availability

Enrollment peaks, term starts and mass password resets hit the identity provider far harder than daily sign-ins do. The patterns below separate the identity tier, the LMS tier and the monitoring layer so each can be sized, patched and failed over on its own schedule.

Clustered Keycloak across availability zones

Run Keycloak as a cluster spread across availability zones, backed by a database that Keycloak supports and that replicates synchronously. Keycloak's high availability designs both require synchronous replication, so an asynchronous replica is not a valid failover target for sign-in. Confirm the database engine and version against the supported list before you commit to a topology, and confirm that the cluster sustains your peak login rate in load tests, not in vendor sizing estimates.

Operator-managed Kubernetes deployment

Deploy Keycloak with the Keycloak Operator, which manages Keycloak, realm import and OIDC and SAML client resources as code. Set the operator to manual approval mode so that upgrades happen only after your team has tested them against a staging copy of the realm configuration. Ask the partner how client definitions are version-controlled and who approves each upgrade window.

Stateless LMS tier scaled separately

Keep the Moodle web tier stateless, with sessions and file storage held outside the application nodes, so course traffic can scale up before a term starts without resizing the identity tier. Moodle 5.1 and later require the web server document root to point to the /public directory, and the database versions differ between Moodle releases. Confirm the PHP, database and storage versions for your target release before sizing the tier.

Read-only fallback or secondary site

Plan what students can still do when the primary identity site is down. Options include a warm secondary site with a replicated database, which still needs a tested cutover, or a degraded mode in which already-issued sessions continue and new sign-ins wait. Each option has a different exposure for password resets and MFA enrollment, so write the expected behavior for each application before an incident. Ask the partner to demonstrate the failover in a test window.

Metrics and logs into the campus stack

Export Keycloak metrics and send authentication and admin event logs to the institution's existing monitoring and log platform, so that sign-in failures, latency and lockouts appear beside LMS and network data during a peak. Agree the metrics endpoint exposure, retention period and alert thresholds with the central IT operations team before go-live. Confirm which events are needed to answer FERPA disclosure logging questions.

Load and failover proof before term

Clustering and capacity are assumptions until a test proves them. Run sign-in load that matches the expected peak, including a simulated mass password reset, and rehearse a node loss and a database failover during that load. Record the measured login rate, error rate and recovery time, and compare them with the peak you planned for. Require the partner to deliver these results in writing as part of the scope.

Evidence auditors and regulators ask campuses for

This table maps the evidence a campus typically needs to the component that produces it, the FERPA or security expectation it supports, and where records usually go missing. Read it as a checklist for the identity and Moodle stack, and confirm each item with your own auditors and counsel. DeployOpen prepares this evidence during implementation but does not issue audit reports or certifications.

Evidence item	Source component	What it supports	Where it usually fails
Realm or tenant configuration exports	Keycloak realms or equivalent identity tenant	Shows client registrations, protocol mappers and session settings are documented and version controlled	Exports taken by hand after changes, with no record of who changed what
SAML metadata and federation agreements	Keycloak SAML clients and identity federation with research and education networks	Shows which external identity providers are trusted and which attributes are released to Moodle	Expired certificates, stale metadata, or attribute release broader than the agreement
MFA policy and enrollment records	Keycloak authentication flows and enrollment reports	Supports person or entity authentication and MFA expectations for staff and administrators	No enrollment count by population, or exceptions granted without an approval trail
Authentication and admin event logs	Keycloak event logging forwarded to a SIEM	Supports audit controls over access to systems that hold student records	Logs kept on the identity server only, with short retention or missing admin events
FERPA disclosure and access records	Moodle and Student Information System logs, with request tickets	Supports the record of each request for and disclosure of personally identifiable information under 34 CFR 99.32	Disclosures made through exports or integrations that never reach the log
Account lifecycle reports tied to the student information system	Provisioning source, identity directory and Moodle enrolment sync	Shows accounts for leavers and graduates are disabled, and that access follows enrolment	Manual account creation for guests or contractors with no end date
Moodle version and patch records	Moodle core and plugin inventory, release notes and upgrade logs	Shows the LMS runs on a supported release, such as a current LTS, with applied security updates	Plugins left behind after upgrades, or sites not moved to the /public document root
Keycloak version and upgrade records	Keycloak release, database migration logs and operator update approvals	Shows the identity provider is patched and changes are approved and reversible	Automatic operator upgrades without a test environment or recorded approval
Restore test results	Database backups for Keycloak and Moodle, restore runbooks	Shows the identity and learning services can be recovered during an incident or peak term	Backups never restored in a test, or identity and LMS databases restored out of step

What do campuses ask before hiring help with SSO?

What drives the cost of a campus SSO project?

Cost follows scope: the number of applications to integrate, how many federations and directories must be connected, how complex the directory structure is, how many LMS plugins need configuring, and how much high availability the design requires. Each application with its own login logic, each federation agreement and each directory source adds testing and coordination work. One-time costs cover design, integration, testing and cutover. Recurring costs cover hosting, database operations, upgrades, monitoring and support. Ask any partner for a quote that lists applications, federations, directories, LMS plugins and HA assumptions separately, so you can compare options on the same basis.

How long does a campus SSO rollout take?

The duration depends on the agreed scope, so no general figure applies. A rollout covering one LMS and a single directory is far shorter than a rollout that adds research and education federation, several SAML applications and self-service recovery across a large student population. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask the partner for a phased plan with a written milestone for each application, and confirm which dates depend on your own change freeze windows, application owners and vendor responses.

What does the institution need to provide for an SSO project?

The project needs people and access more than hardware. Expect to supply:

Named application owners for each LMS, library, portal and third-party tool, who can confirm login behavior and approve testing
Read access to the authoritative student and staff directories, plus a decision on which attributes may be shared with each application
Federation contacts who can complete metadata exchange and attribute release agreements
Test accounts for students, staff, alumni and guests, covering each role that will log in
A change window and a rollback owner for cutover

Missing any of these typically stretches the schedule, so confirm them in the written scope before work begins.

Can a small campus IT team run Keycloak after handover?

A small team can run it if the handover includes a documented upgrade routine and the team has time to follow it. Keycloak plans four minor releases a year and says breaking changes in a minor release are opt-in, which makes routine upgrades more manageable than large jumps. The current release is 26.8.1, published October 13, 2026. For the LMS, Moodle 5.3 is the current LTS release, with general support until 4 October 2027 and security support until 1 October 2029, while Moodle 4.5 has security support until 4 October 2027. Plan around these dates and confirm the support window for your version before committing to a schedule. Ongoing support and upgrades are available as retainers.

How is student account recovery kept safe?

Self-service recovery is a common attack path, so it should not rely on a single weak factor. Good designs verify identity through a second channel that the institution already trusts, limit the number of attempts, log every recovery event, and notify the account holder when a recovery or factor change occurs. Staff-assisted recovery should require a documented identity check and a record of who approved it. Settle the recovery flow, lockout thresholds and help desk procedure in the design phase, and test them with real student scenarios before go-live. For federated students, confirm whether recovery happens at the home institution or at the campus identity provider.

How does DeployOpen produce a quote for campus SSO?

DeployOpen does not publish a price list. A quote follows from the written scope, which lists the applications and protocols in scope, the federations and directories to connect, the LMS plugins and integration work, the high availability design, the testing and cutover approach, and the handover and support options. Work is usually fixed-scope, so changes to the scope are agreed in writing before they affect the quote or timeline. To compare proposals, ask each provider to itemize one-time work separately from recurring support, and to state what they expect the institution to supply.

Which student data rules should shape the SSO design?

Two federal rules shape many campus designs. FERPA's regulations in 34 CFR Part 99 require institutions to limit access to education records to school officials with a legitimate educational interest, which means the identity provider should release only the attributes each application needs. Institutions must also keep a record of disclosures of personally identifiable information. If a contractor is granted access to records as a school official, it must be under the institution's direct control and follow redisclosure limits. Confirm applicable obligations with counsel and your compliance office, because the rules depend on your funding and student population.

What to ask an education SSO implementation partner

Start with federation experience, because a partner who has only wired applications to a local directory will struggle with a research and education identity federation. Ask for examples of SAML metadata exchange, including how they validate the entity descriptor, certificate rollover dates and the metadata refresh process. Ask how they decide which attributes to release to each service provider, and how they document that release so the campus identity office can defend it. Ask them to show a sample EntityDescriptor and the attribute release policy they would hand over at the end of the engagement. Confirm which federation operator and metadata rules apply in your country or network, since these are outside what this page can state.

Next, ask how they test enrollment-peak load and what they will measure. A credible answer names a test plan built around the real first-week login surge, the Keycloak clustering design and the database tier, with pass criteria agreed in writing before testing starts. Ask how they validate that the database is synchronously replicated in the high availability design Keycloak documents, and how they prove failover during a login burst rather than assuming it. Also ask how they handle legacy applications that support neither SAML nor OIDC, such as older library systems or departmental tools. The answer should involve a gateway or proxy pattern, a named owner for each exception and a list of applications that stay outside SSO. Ask for that list in the first proposal.

Then press on the parts that carry the most risk after go-live. Ask how Moodle upgrades are tested against authentication settings, since the auth plugins in Moodle core, including LDAP, OAuth 2 and Shibboleth, can break silently after a major release, and confirm the minimum Moodle version your site must be on before an upgrade. Ask how account recovery avoids social engineering: the partner should describe identity verification steps for help desk resets, the rules for recovery through personal email or phone, and how MFA re-enrollment is approved. Ask what happens when the identity provider is down, including the fallback for LMS access during exams and the procedure for emergency local accounts. Finally, ask who holds the evidence after handover: configuration exports, test records, runbooks and access logs should be stored in a location the institution controls, with named custodians and a retention period agreed in writing.

How DeployOpen scopes and supports campus SSO

A campus SSO project touches the identity provider, the LMS, research federation and the help desk, and each one needs an owner. The cards below describe how DeployOpen agrees the work in writing, builds it inside your infrastructure and keeps it running after launch.

Fixed scope agreed in writing

Before any build starts, the applications to federate, the protocols each one uses, the directories to connect and the account recovery rules are agreed in a written scope with deliverables and timelines. Ask the partner to list which LMS, library and research applications are in scope and which are deferred. Anything not listed is a change request, so confirm how that change is priced and approved.

Deployment in your own infrastructure

Keycloak or authentik runs in the institution's own cloud account, data center or private network, so student and staff identity data stays under the institution's control. The partner should confirm the hosting model, the database choice and how the identity provider is kept available during enrollment peaks such as the start of term. Ask who holds administrator credentials at handover.

Keycloak or authentik and LMS integration

The identity provider is configured for SAML and OpenID Connect clients, and the LMS connection is set up through the authentication plugins your Moodle version supports. Check that role mapping, course enrollment attributes and logout behavior are tested with real student and instructor accounts before cutover. Confirm which Moodle version and PHP and database versions the partner has verified.

Hardening the login flow

Hardening covers the settings that decide who gets in and how sessions behave: MFA enrollment for staff and privileged accounts, brute-force protection, password and passkey policy, session lifetimes and secure cookie settings. The partner should show the production configuration it applies and explain how it is reviewed. Ask how changes to these settings are tested before they reach students.

Security testing of the login flow

Testing targets the login, password reset, federation and LMS callback paths for weaknesses such as open redirects, token leakage and account recovery abuse. Results should arrive as a written report with prioritized findings and retest evidence. Ask whether testing is done before launch and repeated after each upgrade, and who fixes the findings.

Evidence and retainers after launch

DeployOpen prepares configuration exports, access reviews and logs that an institution's compliance team or external auditor can examine, but it does not issue audit reports or certifications. Upgrades, patching and ongoing support run under a retainer, which should define response expectations, upgrade testing and who approves changes. Ask for a sample evidence package and the upgrade process before you sign.

Open source SSO for education