Open source SSO for public sector: why agency identity is different
Open-source SSO can run on government-controlled infrastructure, and the control framework, more than the software, sets most of the design. Federal agencies usually map identity to NIST SP 800-53 Rev. 5, where control IA-2 covers how organizational users are identified and authenticated, including multi-factor authentication where the selected baseline requires it. Release 5.2.0 of SP 800-53 (27 August 2025) is the current catalog, and the SP 800-53B baseline chosen for the system determines how many controls apply. Authentication strength comes from the assurance levels in SP 800-63B-4, so the first task is to confirm with the authorizing official which assurance level each application group needs. Those answers, not the product name, decide the MFA factors, session lifetimes and account recovery paths.
The three main candidates are Keycloak, FreeIPA and ZITADEL, and each fits a different mix of needs. Keycloak, licensed under Apache-2.0, supports OpenID Connect, OAuth 2.0 and SAML 2.0 and federates LDAP and Active Directory, so it suits agencies with many web applications and an existing directory. FreeIPA combines 389 Directory Server, MIT Kerberos and the Dogtag certificate authority, which makes it a stronger fit when Kerberos login and certificates from the agency's own CA are central. ZITADEL, licensed under AGPL-3.0, lists SAML 2.0, SCIM and passkeys (FIDO2 and WebAuthn) among its features. Before shortlisting, confirm smart card and PIV or CAC login support, certificate-based authentication into each application, and the protocols that legacy applications require, because those requirements narrow the field faster than feature lists do.
FedRAMP scope depends on how the identity service is delivered, so settle that question early. FedRAMP covers cloud products and services that handle federal information on behalf of an agency, while a system used only for one agency's operations on cloud infrastructure, and not offered as a shared service, falls outside it. An identity provider running on agency-controlled servers in an agency data center sits outside that boundary by design, but a hosted identity service shared with other agencies or tenants may not. Ask the agency's compliance lead to document where the identity provider runs, who operates it and who can administer it, using the FedRAMP scope guidance under OMB M-24-15 as the reference. DeployOpen plans, deploys and documents the system and prepares the evidence, but it does not issue authorizations or audit reports. The authorizing official and independent assessors make those decisions.
Which public sector requirements shape the SSO build
This table maps each public sector requirement to what it means for a self-hosted SSO build, including MFA, certificate login, key strength, logging and where the identity provider may run. Read each row against your agency's system security plan and assurance level, because the applicable baseline and IA-2 enhancements decide how strict each control is.
| Requirement | What it asks for | What it means for the SSO build |
|---|---|---|
| NIST SP 800-53 Rev. 5 and SP 800-53B baselines | Federal control catalog. SP 800-53B selects 149 controls and enhancements at low, 287 at moderate and 370 at high. | Identify your impact level first, then confirm which IA controls and enhancements apply to the identity provider, its database and its admin consoles. |
| IA-2 identification and authentication | Organizational users must be uniquely identified and authenticated, with multi-factor options defined by the baseline and enhancements. | Enforce MFA for network and privileged access, bind every login to a unique account and confirm which IA-2 enhancements your baseline requires. |
| FISMA and OMB Circular A-130 (legal basis) | FISMA makes agencies responsible for system security, with Inspectors General assessing it and reporting to OMB. Circular A-130 sets the federal management policy. | Expect the identity provider to be in the authorization boundary and in continuous monitoring, so keep configuration, change and assessment evidence for it. |
| FedRAMP scope under OMB M-24-15 | Cloud products that handle federal information on behalf of an agency are in scope. Single-agency systems not offered as a shared service are out of scope. | If the identity provider runs in a cloud account for one agency only, it may fall outside FedRAMP, but confirm the scope determination with your authorizing official. |
| CJIS Security Policy v6.1 cryptography | For criminal justice information outside physically secure locations, use FIPS 140-3 validated modules or AES with at least 256-bit keys, and scan for vulnerabilities at least monthly. | Confirm the Keycloak or FreeIPA crypto modules, TLS settings and database encryption are FIPS-validated and set to 256-bit AES where CJI is involved. |
| Certificate-based and smart card login | Assurance levels in NIST SP 800-63B-4 and agency policy may call for PIV or CAC style, phishing-resistant authentication. | Plan certificate issuance, revocation and CRL publication. FreeIPA's integrated certificate authority or an external PKI may be the trust anchor, so confirm which one your policy accepts. |
| 32 CFR 2002.14(h)(2) for CUI on non-federal systems | Agencies apply NIST SP 800-171 when setting protections for CUI on non-federal systems, unless the CUI category prescribes other safeguards. | If contractors or partner staff log in to the identity provider for CUI, the identity provider and its hosting must meet the agency's SP 800-171 requirements. |
| User activity logging and audit | Record and review authentication events, privileged changes and access decisions, and keep them for the period your records schedule requires. | Forward login, failure, MFA, admin and certificate events to your SIEM. Confirm retention and tamper protection with your records office. |
| Where the identity provider may run | Systems handling federal or CJI data must run within the boundary approved by the authorizing official, which may exclude foreign or shared hosting. | Run the identity provider and its database on government-controlled infrastructure where your boundary requires it, and document data residency and administrator location. |
Which open-source platforms fit agency SSO and why
Agencies adopting self-hosted single sign-on usually narrow the field by protocol support, directory integration and license terms before comparing features. The cards below cover the platforms most often considered for workforce login on government-controlled infrastructure, with the license and procurement questions each one raises.
Keycloak for broad protocol coverage
Keycloak is an Apache-2.0 identity server that supports OpenID Connect, OAuth 2.0 and SAML 2.0, and federates LDAP and Active Directory user stores. For agencies, its Apache-2.0 license is usually the simplest to document in procurement reviews. The current release is 26.8.1, so the first task is to fix a supported version and an upgrade cadence. Confirm how each candidate Keycloak build handles the smart card and certificate login your assurance level requires, using a pilot with your own card readers and certificate authority.
FreeIPA for Kerberos and certificate-based identity
FreeIPA combines the 389 Directory Server, MIT Kerberos, the Dogtag certificate authority and OTP tokens in one GPL-3.0-or-later package. It suits agencies that run Linux and Windows estates and want an internal certificate authority under their own control. Its cross-forest trust with Active Directory requires a DNS domain that does not overlap the AD forest, so plan the naming before installation. Because it is a community project without a paid edition, budget for internal or partner support.
ZITADEL for passkeys and multi-tenancy
ZITADEL is an AGPL-3.0 platform that lists SSO, MFA, passkeys through FIDO2 and WebAuthn, SAML 2.0, SCIM and multi-tenancy. Agencies that serve several departments or contractor groups from one identity service may value its tenant model. AGPL-3.0 carries network-use source disclosure duties when the software is modified and offered to users, so legal review should happen before any custom changes. Confirm which smart card and PIV-style certificate flows the current release supports, since passkey support does not answer that question.
authentik for mixed-license procurement
authentik is MIT licensed except the authentik/enterprise directory, which carries a separate enterprise license. Procurement teams should separate the MIT core from any enterprise features the design depends on, and record which directory is in use. The 2026.8.4 release is the reference point for a pilot, and the pilot should test provider flows for each application and any certificate-based login path. A license review of the enterprise directory is needed before the agency relies on any of its features in production.
Ory Kratos and Hydra for API-first services
Ory Kratos handles identity and user management, and Ory Hydra provides an OAuth 2.0 and OpenID Connect server, both under Apache-2.0 and both at v26.2.0. They fit agencies that build their own login screens and need identity as an API for citizen-facing or internal services. They do not provide a full administrative console in the way Keycloak does, so staff workflows, policy administration and audit views must be built or assembled. Confirm the workforce features you need, such as smart card login and administrator approval, before choosing this path.
Procurement and license checks for agencies
Open-source licenses differ on obligations that procurement and legal teams review: Apache-2.0 and MIT are permissive, GPL-3.0 applies copyleft to distributed modifications, and AGPL-3.0 extends source obligations to networked use. Agencies should record the license of each component, any separately licensed enterprise directory, and the vendor or community that provides security patches. Smart card and certificate login support is not uniform across these products, so it must be confirmed in a pilot against your own cards, certificate authority and assurance requirements before a platform is selected.
How an agency SSO rollout moves from design to operation
The sequence turns agency assurance and control requirements into a self-hosted identity provider that is tested, integrated, backed up and handed over with evidence. Each phase closes with a named output, and the agency signs off before the next phase starts. Timelines are set in the written scope.
Map assurance levels and controls
The team starts by agreeing which applications and user populations fall under which NIST SP 800-63B-4 assurance level, and which SP 800-53 controls, including IA-2 for multi-factor authentication, the agency must evidence. The agency's security office, the system owner and the DeployOpen architect take part, and the agency's authorizing official or its delegate confirms the scope. The output is a control mapping that lists each requirement, the component that meets it and the evidence it will produce. The step is done when the agency signs that mapping. Confirm with the agency's assessor which baseline from SP 800-53B applies to the system.
Design directories and certificate trust
Next, the team decides where user identities live, how Keycloak or FreeIPA federates with existing agency directories, and how smart card and certificate authorities are trusted. It also covers which users need PIV or CAC style credentials, how certificate revocation is checked, and where the identity provider's keys and certificates are generated and stored. DeployOpen documents the design, including directory sources, realm or domain layout, certificate chains and network paths. The output is an approved design document and a hardware and network inventory. The step is done when the agency's directory owner and PKI owner sign off the trust model.
Pilot smart card and token enrollment
A small pilot group logs in with the intended methods, such as smart card or certificate login, hardware tokens or other MFA factors, against a non-production copy of the identity provider. Testers check login, lockout, token enrollment, recovery and the behavior when a card or token is lost. DeployOpen records the results and the configuration exports that auditors will need. The output is a pilot report with defects logged and resolved, and an enrollment procedure for help desk staff. The step is done when the agency accepts the pilot results in writing.
Integrate applications in controlled waves
Applications move onto the identity provider in groups rather than all at once. Each wave covers the protocol each application supports, such as SAML 2.0 or OpenID Connect, its claims and group mappings, its session rules and its logout behavior. Applications that cannot use SSO are listed with the compensating controls the agency approves. Each application owner runs acceptance tests with the agency's test accounts. The output is an integration record per application and a list of exceptions. The wave closes when the owner signs the test result and the old login path is retired or formally kept.
Test high availability and backups
The team builds the production topology, then tests failover of nodes and, where the design includes it, failover between sites. It also runs a backup and restore test into a separate environment, and checks that restored data behaves correctly against the replication and certificate renewal setup. Key facts to verify include the database that supports the chosen high availability design and the backup procedure of the chosen platform. The output is a test report with recovery steps and measured results. The step is done when the agency's operations lead accepts the recovery procedure.
Set the operator and upgrade process
DeployOpen documents how platform updates are reviewed, tested in a staging copy, approved and applied. For Keycloak deployments on Kubernetes, the team sets the Operator update approval mode to manual, and agrees whether database schema migrations run automatically at startup or are applied by hand. The change board, the patch window and the rollback steps are written down. The output is an approved runbook and a signed change record for the first upgrade. The step is done when the agency has run one upgrade through the runbook in staging.
Hand over operations and evidence
The final phase transfers the platform to the agency or to its chosen operator. DeployOpen delivers the architecture, configuration exports, control mapping updates, test reports, backup records, the runbook and the access list for administrators. Staff are trained on enrollment, incident handling and administration. The output is a signed handover package and an evidence index that maps each control to the artifact that supports it. Independent assessors decide whether that evidence is sufficient. Ask the implementation partner for the handover contents in the written scope before work starts.
How government-controlled hosting changes the SSO architecture
Running the identity provider in agency data centers or inside a government cloud boundary changes the architecture before any protocol is chosen. The first decision is whether the identity service will be a shared service or a system used only by one agency. FedRAMP's scope, set by OMB memo M-24-15, covers cloud products that create, collect, process, store or maintain federal information on behalf of an agency, and it excludes systems used only for a single agency's operations on cloud infrastructure that are not offered as a shared service. Confirm with your authorizing official and the agency's cloud governance team which side of that line a multi-agency SSO platform falls on before you pick a hosting model, because the answer determines whether the provider must hold an authorization or whether the agency's own assessment covers it.
Availability design follows the same logic. Keycloak documents three high availability architectures, and both supported designs require a synchronously replicated database, so the database platform, its replication mode and its failover tests are part of the SSO design, not an afterthought. Confirm which of the supported production databases your agency already runs and operates under its own controls. For FreeIPA, the project's deployment recommendations call for at least two to three replicas in each datacenter, no more than four replication agreements per replica, and dedicated servers. Plan backups with ipa-backup and rehearse ipa-restore in a lab. FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication, and that the first server handles certificate renewal and CRL publication by default. Agencies should document which server holds those roles and who approves any restore.
Patching cadence is where government hosting often adds the most delay. Keycloak plans four minor releases a year, and its Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Set that approval mode deliberately, keep a dated change record for each upgrade, and test schema migration in a copy of production before approving it. Keycloak migrates its database schema automatically at startup by default, and the upgrading guide suggests manual migration for large deployments, so decide which path your change process can support. Ask your implementation partner to show how a patch is tested, approved and rolled back inside the agency's own change window.
What auditors and inspectors ask for from agency SSO
This table lists the evidence an assessor or inspector typically asks to see for an agency identity provider, which component produces each item, and where it usually goes missing. Read each row as a question to answer before an assessment, not as a checklist of pass or fail results. DeployOpen prepares this evidence from your environment, but independent assessors decide whether it is adequate.
| Evidence | Produced by | What assessors check |
|---|---|---|
| MFA configuration exports | Keycloak realm and authentication flow exports, or authentik and ZITADEL policy exports, depending on platform | Which applications and roles require MFA, which factor types are allowed, and whether the export matches the policy approved by the agency |
| Role and group mappings | Keycloak groups and role mappings, FreeIPA groups and host-based access control rules, directory exports | Who holds administrative roles, whether mappings follow approved access requests, and whether privileged groups are reviewed |
| Authentication and admin event logs | Keycloak event and admin event logging, FreeIPA server logs, forwarded to the agency log platform | Unique user identification, failed and successful logins, administrative changes, and retention for the period the agency's policy sets |
| Certificate issuance and revocation records | FreeIPA Dogtag certificate authority records, including issuance, renewal and revocation, for smart card and certificate login | Who requested and approved each certificate, serial numbers, and whether revoked certificates are published and honored at login |
| Smart card and PIV login configuration | Keycloak or FreeIPA certificate-based authentication settings and the trust chain they use | Whether the accepted certificate authorities match the agency's approved issuers and whether revocation checks are enforced |
| Backup and restore test results | FreeIPA ipa-backup and ipa-restore runs, and documented restore tests for Keycloak database backups | Dated restore tests in a separate environment, with recorded outcomes and the time taken, not only backup job success messages |
| Change records for upgrades | Keycloak release notes review, upgrade test records, Operator update approvals, and FreeIPA patch records | Each upgrade tied to a change ticket, a pre-production test, an approver, and a rollback plan |
| High availability and failover tests | Keycloak cluster and database replication configuration, FreeIPA replica topology records | Documented failover tests showing that authentication continues when one site or replica is lost |
What agencies ask before hiring an SSO partner
What drives the cost of a public sector SSO rollout?
The main drivers are the number of directories to federate, the number of applications to integrate, the smart card and certificate work, the high availability design, and the compliance evidence the agency must produce. Each directory adds mapping and attribute work, each application adds a protocol integration and testing cycle, and smart card login adds certificate chain, revocation and reader configuration. Costs are split between a one-time build (design, integration, hardening, documentation) and recurring items (patching, upgrades, monitoring, support). Ask any partner for a quote that lists these items separately, names which directories and applications are in scope, and states what is excluded. The scope agreed in writing is what sets the final figure.
How long does an agency SSO rollout take?
Duration depends on how many applications and directories are in scope, how many of those applications already support SAML or OIDC, how many users must be enrolled in MFA, and how long the agency's change and approval cycles take. Legacy applications without standard protocols usually add the most time because they need a different integration path. Smart card and certificate login add time for certificate authority coordination and device testing. DeployOpen does not publish timelines, so ask for a phased plan in the written scope that ties each phase to named applications, the test environment and the cutover approval. Treat any single figure given before the scope is written as provisional.
What does the agency need to provide for an SSO project?
The agency must provide the people and information that only it holds. That includes an inventory of applications with their protocols and owners, the directories and attribute sources to federate, the certificate authority or PKI trust chain for smart card users, the network and DNS zones where the identity provider will run, and named approvers for security, change control and cutover. Agencies also need to decide the MFA and session policy, the assurance level each application requires, and who will own user lifecycle decisions. Ask the partner to produce a written list of these inputs before work starts, with a due date for each, because missing inputs are the most common reason a fixed scope slips.
Can an internal team run a self-hosted Keycloak deployment?
An internal team can run it if it has skills in Linux, databases, certificate management, Kubernetes or the chosen deployment method, and on-call coverage for an identity provider that many systems depend on. Keycloak supports several production databases and documents high availability designs that need a synchronously replicated database, which adds operational work. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates, so someone must review each update. Agencies often split the work: the internal team owns daily operations and user administration, while a partner handles design, hardening, upgrades and documentation under a retainer. Decide this split in writing before the rollout begins.
How are Keycloak upgrades and patches handled in production?
Upgrades should follow a tested, documented procedure in a non-production environment that mirrors production. Keycloak plans four minor releases a year since version 26.0 and says breaking changes in a minor release are opt-in, which reduces surprise but still requires testing of custom providers, themes and client configurations. Keycloak migrates its database schema automatically at startup by default, while the upgrading guide suggests manual migration for large deployments, so the agency should choose the method deliberately. For FreeIPA, the 4.13.4 release fixed two CVEs, which shows why security patch tracking matters for every component in the stack. Ask the partner how they test each upgrade, how they back up before changing the schema, and how they document the rollback path.
Does FedRAMP apply to a self-hosted SSO deployment?
FedRAMP applies to cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. According to the FedRAMP scope rules under OMB M-24-15, systems used only for a single agency's operations on cloud infrastructure, and not offered as a shared service, are out of scope. An identity provider that an agency runs on its own government-controlled infrastructure generally falls outside that cloud definition, but the answer depends on how the system is hosted, who operates it and whether a third-party cloud service is part of the identity flow. Ask the agency's authorizing official or compliance office to confirm the boundary in writing. DeployOpen does not issue FedRAMP authorizations.
How is smart card login tested before go-live?
Smart card login should be tested against every card type, reader model, operating system and browser the agency uses, using a test environment that carries the same certificate chain as production. Testing should cover certificate validation, revocation checking, user-to-certificate mapping, expired and revoked cards, fallback behavior when the card or reader fails, and the MFA step that follows where policy requires it. Keycloak and FreeIPA each provide certificate-related capabilities, and the exact configuration should be confirmed against the vendor documentation and the agency's PKI policy. Ask the partner for a written test plan with pass criteria, a record of results, and a defined procedure for re-testing after each change to the certificate authority or the identity provider.
What to ask an implementation partner for agency SSO
Start by asking the partner to map each NIST SP 800-63B-4 assurance level your agency needs to specific identity provider settings, and to show how each IA-2 enhancement under SP 800-53 is met. Ask for the authentication flow per application, the realm or client settings that enforce it, and the evidence each setting produces. A partner who answers with a generic statement about MFA has not done this mapping. Ask which assurance level each application is assigned and who signs off on that assignment, because the agency owns that decision, not the integrator.
Ask how smart card and certificate login will be tested across each client type in use, including managed Windows workstations, browsers, mobile devices and any shared terminals. Ask which certificate authority issues the certificates, how revocation status is checked during login, and what happens when a card is lost or a certificate expires. Ask how the identity provider stays on government-controlled infrastructure: which cloud accounts, data centers or air-gapped networks host it, who holds administrator credentials, where logs and backups are stored, and how the partner's own access is granted, recorded and removed.
Ask how Active Directory trusts will be built, including how DNS namespaces are separated, and how legacy applications that cannot speak SAML or OIDC will be fronted or migrated. Ask how upgrades are tested against a staging copy of the production realm, whether the partner follows the Keycloak Operator guidance to use manual approval for updates, and how schema migrations are rehearsed. Ask what happens when the identity provider is down: which high availability design is proposed, how the database is replicated, which applications keep working from cached sessions, and what break-glass access exists. Finally, require the written scope, deliverables and evidence list before any work starts, including the configuration exports and test records the agency will receive.
