How to use this SSO requirements checklist before a rollout
A team asked to replace or add workforce login should write its requirements baseline before it compares any platform. The checklist on this page lists what a workforce single sign-on rollout has to do, from the protocols each application needs to the applications that cannot use SSO at all. The requirements decide the shortlist, not the other way round. Keycloak, authentik, ZITADEL and FreeIPA are each assessed later on this page against the items you have confirmed, so the baseline has to exist first.
The checklist is organized into five groups: functional, security, integration, operational and compliance. Functional items cover the protocols each application needs (SAML 2.0 or OpenID Connect), the directories to federate, and branding. Security items cover MFA and passkey policy, session rules and audit logging. Integration items cover provisioning and deprovisioning, including whether an application accepts SCIM. Operational items cover high availability, upgrades and what users experience when the identity provider is down. Compliance items map each requirement to the evidence an assessor will ask for.
Treat every item as something to verify, not something a vendor has promised. For each requirement, name the test, configuration export or document that proves it, such as a sample SAML metadata file, a login test with a passkey on a non-admin account, or a deprovisioning run against a test user. Keep a separate list of applications that cannot do SSO, because those usually drive the largest share of the work. Confirm each open item with the application owner, the directory owner or the vendor in writing before the shortlist is finalized.
Functional SSO requirements: protocols, directories and application inventory
This table lists the functional requirements to settle before choosing or configuring a workforce SSO platform, from the protocol each application speaks to the directories and attributes that feed it. Each row states what to decide, why it matters and how to verify it with a test before cutover. Keycloak documents SAML 2.0, OpenID Connect, OAuth 2.0, LDAP and Active Directory federation, while ZITADEL and authentik list SAML, OIDC and LDAP support, so confirm each application's needs against the chosen platform's documentation.
| Requirement | What to decide or confirm | Why it matters | How to verify |
|---|---|---|---|
| Application inventory | Every workforce application, its owner, login method today (SAML, OIDC, OAuth 2.0, LDAP, Kerberos, header-based or local password) and whether it supports single logout | The protocol drives the integration pattern and effort, and an incomplete list is the most common source of late scope changes | Confirm each entry with the application owner and a test login in a non-production copy; record the protocol and version from the application's admin settings |
| SAML 2.0 applications | Entity IDs, assertion consumer URLs, required NameID format, signing certificate, encryption requirements and clock skew tolerance | Mismatched metadata is the usual cause of failed SAML logins, and certificate expiry can stop access without warning | Exchange metadata files, run a test login and inspect the SAML response in a browser tool; check the certificate expiry date |
| OpenID Connect and OAuth 2.0 applications | Client type (confidential or public), redirect URIs, scopes, token lifetimes and whether the app needs refresh tokens or a device flow | Redirect URI mismatches and wrong client types cause errors that look like platform faults | Run an authorization code login per client, confirm the ID token claims and test a refresh and a logout |
| LDAP, Kerberos and header-based applications | Whether the app binds to LDAP directly, needs Kerberos or SPNEGO for Windows integration, or trusts a reverse proxy header for identity | These applications often cannot speak SAML or OIDC, so they need a gateway, proxy or a separate authentication path | Test each path with a sample account; confirm which systems will stay on local passwords and record them as exceptions |
| Directories to federate | Active Directory domains, LDAP or OpenLDAP trees, upstream identity providers and any local accounts that must remain | Federation scope determines which accounts can log in, and overlapping sources can create duplicate identities | Run a directory sync dry run with a read-only bind account and compare returned user and group counts with the source |
| User attributes and group mapping | Attributes each app needs (email, employee ID, department, roles), the source attribute for each and the group-to-role rules | Missing or inconsistently named claims are a frequent cause of access errors and of over-broad access | Build a sample attribute mapping table and check claims for three test users covering common roles and edge cases |
| Authentication source for each application | Whether the platform or the upstream directory verifies passwords, and which apps must accept the same password store | Clarifies who owns password policy and lockout, and avoids two sources disagreeing about the same account | Document the authoritative source per attribute and test a password change and a disabled account in both directions |
| Branding per application | Logo, colors, login page text and whether each application or customer organization needs its own login page | Staff are more likely to recognize a legitimate login page, and branding affects support volume during rollout | Review login pages on the supported browsers and confirm the brand assets with communications and security teams |
| Protocol and version support confirmation | Which protocols the chosen platform supports in its current release, and any features that are edition-specific | Feature availability can differ between community and paid editions, so the requirement must match the edition selected | Check the platform's current documentation and the release notes for the version under evaluation, and test every protocol in a lab |
Which MFA and passkey policy to settle before choosing a platform
Write the MFA and passkey policy as a set of requirements before you compare platforms, because each product handles enrollment, token types and recovery differently. Start by naming the user groups that must authenticate with a second factor (all workforce staff, contractors, vendors, and anyone reaching systems from outside the corporate network), then list the applications each group uses and the assurance level each application needs. Separate the privileged roles, such as identity administrators, database administrators, cloud owners and break-glass accounts, and set a stricter rule for them, for example phishing-resistant factors only and no fallback to a one-time code sent by SMS or email. Record which applications accept only a password today, since those gaps decide whether MFA can be enforced at the identity provider or must be added at the application.
The regulatory drivers set the floor. The HIPAA Security Rule's person or entity authentication requirement at 45 CFR 164.312 expects covered entities and business associates to verify that a person or system seeking access to ePHI is who or what it claims to be, and the FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to apply multi-factor authentication to any individual accessing an information system. Neither text prescribes a factor type, so your policy must state which methods satisfy your own risk assessment and document why. Ask your compliance lead and counsel to confirm the exact scope of each rule for your organization before the policy is final.
Passkeys need their own decisions. ZITADEL documents passkeys based on FIDO2 and WebAuthn with fallback to password login, which shows that passwordless and password paths can coexist, but a fallback to password weakens the policy for privileged roles. Decide whether passkeys are optional or mandatory per group, how new users enroll them, and what happens when a device is lost. Then confirm, in the current release of each shortlisted platform, which passkey types, hardware keys, TOTP or push factors, and recovery options it supports, and how those settings can be scoped to a group or application rather than the whole realm or instance.
Security requirements for session, credential and audit controls
These four to six controls define how the identity provider itself is protected, how user sessions and credentials behave, and what gets recorded. Settle them before choosing a platform, because each one changes configuration, operating procedures and the evidence an assessor will ask for. For each card, the question is what your policy requires, then what the platform export or log sample proves.
Session lifetime and idle timeout
Decide the maximum session lifetime, the idle timeout, and whether sessions are re-authenticated before sensitive applications are opened. Set separate values for staff on shared workstations, for administrators and for applications that hold regulated data. Ask the implementation partner to show the realm or tenant session settings as an export, and to demonstrate a session expiring in a test browser. Confirm how each client application honors logout, since SSO sessions and application sessions can expire at different times.
Password and lockout policy
Decide minimum length, complexity or passphrase rules, password history, breached-password screening, and how many failed attempts trigger a temporary lock. Confirm which rules apply to local accounts and which are delegated to an upstream directory, because a rule set in the identity provider may not reach an account authenticated against Active Directory. Request the password policy configuration export and a log sample showing a lockout event.
Token signing and transport encryption
Decide which signing algorithms and key lengths are permitted for SAML assertions and OIDC tokens, how signing keys are rotated, and that all browser and back-channel traffic uses TLS with approved protocol versions and cipher suites. Confirm whether assertions are encrypted, not just signed, for applications that carry regulated data. Request the realm keys listing, the metadata documents for each relying party, and a TLS scan report of the public endpoints.
Administrator access to the identity platform
The identity provider is the highest-value target in the environment, so decide who may hold administrator roles, how those roles are granted and reviewed, and whether administrative consoles are reachable only from a management network. Require MFA for every administrator and separate break-glass accounts with documented custody. Ask for a list of role assignments and the procedure for emergency access, and confirm how the platform records changes made through its admin console and API.
Audit logging of logins, failures and changes
Decide which events are retained: successful and failed logins, MFA enrollment and failures, password resets, session revocations, client and role changes, and administrator actions. Set the retention period, where logs are stored and who can read or alter them, and how they reach the central log platform. Request a sample export containing one login, one failure and one configuration change, and confirm the timestamps and user identifiers are complete.
Secrets and database credential handling
Decide where client secrets, signing keys, LDAP bind credentials and database passwords are stored, who can read them, and how they rotate without an outage. Keep these values out of realm exports, container images and version control, and confirm the database account has only the privileges the platform needs. Ask the partner to show the secret store entries, the rotation runbook and a rotation test in a non-production environment.
How provisioning and deprovisioning requirements are set
Settle how accounts get created and removed before choosing any product. Just-in-time provisioning creates or updates a user in the application at first login, based on the assertion or token the identity provider sends. It is simple, but it never removes anyone: an account persists until someone deletes it or the application disables it. SCIM-based lifecycle sync pushes create, update and deactivate operations from the identity provider to each application over HTTP endpoints. The standards are RFC 7643 (the core schema) and RFC 7644 (the protocol), which define how users and groups are created, read, updated and deleted across domains. Manual account creation remains common for legacy applications and is the hardest to evidence, because every grant and removal depends on a ticket being closed on time.
Deprovisioning timing is the requirement that auditors and security teams ask about first. Before any rollout, write down three things. First, the source of truth for each user, such as an HR system, the directory or the identity provider itself, and which attribute changes trigger a leaver event. Second, the maximum acceptable time to remove access after a leaver event, separately for standard staff and for privileged accounts. Third, the list of applications that do not receive SCIM pushes, along with the owner and the manual step that removes access in each. Keycloak and ZITADEL both support SCIM-style provisioning, and ZITADEL provides a SCIM v2 service provider interface. authentik lists a SCIM provider type among its provider options. Confirm in each product's documentation which operations (create, update, deactivate, delete, group membership) each target application actually honors.
Record these decisions as a short table that maps each application to its provisioning method, deactivation path and the test used to prove removal. Illustratively, a finance application without SCIM support might be assigned a daily access review and a documented disable step, while a collaboration suite receives automatic deactivation from the identity provider. Ask your implementation partner to run a leaver test on a sample account in every application before go-live and to keep the results as evidence. Confirm with each application vendor whether deactivated users keep existing sessions or API tokens, because those can outlive the directory change.
Integration requirements: directories, applications and identity brokering
Before choosing a platform, settle which directories, external identity providers and business systems the SSO service must read from or send data to. Each connection changes who can log in, which roles they receive and what breaks when a dependency fails. The cards below name the decision for each connection and the test that proves it works before cutover.
Directory federation to Active Directory or LDAP
Decide which directory is the source of truth for passwords and group membership, and whether the identity provider reads it (federation) or copies it (synchronization). Confirm which Active Directory forests, domains or LDAP base DNs are in scope, which service account the platform binds with, and whether it needs read-only access. Verify with an end-to-end login test using a test user from each directory, including a disabled account and a user in a nested group. Keycloak supports LDAP and Active Directory user federation, which is a good starting point for that test.
Brokering to external identity providers
Decide which external identity providers, such as Entra ID or Okta, will authenticate some or all users, and whether each customer or partner organization gets its own provider. Confirm which protocol each provider uses (OIDC or SAML), how user attributes are matched to local accounts, and what happens to users who exist in two places. Zitadel can federate with Entra ID, Okta, LDAP and OpenLDAP, and each customer organization can use a different identity provider, so test that path with one account per provider and one mismatched account.
Claim and group mapping into application roles
Decide which claims (for example email, department or group membership) each application needs, and where role decisions are made: in the identity provider, in the application or in a mapping layer. Document the mapping table in writing, including default roles for users with no group and how removed groups are handled. Verify with a claim dump from a sample application for at least one user per role, and confirm that the application rejects tokens without the expected claims. This check often exposes group names that differ between directories.
HR system and source-of-truth feeds
Decide whether joiner, mover and leaver events come from an HR system, the directory or a manual ticket, and which system wins when records disagree. SCIM (RFC 7644) defines HTTP endpoints for creating, reading, updating and deleting users and groups, and Zitadel provides a SCIM v2 service provider interface, but the source feed itself must be confirmed with the HR team. Test a hire, a transfer and a termination with sample records, then confirm that access is removed in every connected application, not only in the directory.
SMTP and notification dependencies
Login flows depend on email for account recovery, verification codes, password resets and admin alerts. Confirm which SMTP relay the platform will use, whether it is reachable from the identity network, which sender domain and SPF or DKIM records apply, and who receives security notifications. Test password reset and one-time code delivery for a user on each mail domain, and confirm what the user sees when mail is delayed. A missing relay often shows up first as a helpdesk ticket, so verify it before pilot users are onboarded.
API clients and service accounts
Decide which machine clients need tokens, such as scripts, backup jobs, monitoring agents and integrations that call the identity provider's admin API. Record each client's owner, grant type, scopes, secret storage location and rotation date, and avoid sharing one account across several systems. Verify with a token request from each client, a test that confirms the client cannot read beyond its scope and a documented procedure for revoking one client without affecting others. Keep this inventory with the audit evidence so reviewers can trace which non-human identities exist.
Operational requirements: high availability, upgrades, backup and support
This table compares the operational requirements an SSO platform must meet after go-live, with the evidence to request for each. Read each row as a question to put to the vendor, your implementation partner and your own operations team. The main takeaway is that database replication, tested restores and staged upgrades decide whether the identity provider stays available, and most of these answers are only trustworthy when they are written down and tested.
| Requirement | Why it matters | How to verify it |
|---|---|---|
| Availability target and failure behavior | Every application login depends on the identity provider, so an outage blocks staff across the estate. Write down which apps must keep working if the provider is down, and whether cached sessions or a break-glass path exist. | Ask for the agreed availability target in writing and a documented failure scenario for each component. Run a node-loss test and confirm which logins still succeed. |
| Database platform and synchronous replication | Keycloak supports MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL (14 to 18), EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL in production. Its high availability designs need a synchronously replicated database, so an asynchronous replica is not enough. | Confirm the chosen database version against the Keycloak database guide. Ask for the replication mode in the target design and a failover test that shows no lost configuration or sessions. |
| High availability architecture | Keycloak documents a single cluster optionally spread across availability zones, multi-cluster deployments (v2) without external Infinispan, and the deprecated multi-cluster v1. Choosing among them affects failover behavior, network latency needs and operating effort. | Record which architecture is chosen and why. Ask the partner to show the cluster topology, the zone layout and the procedure for losing one site. |
| Backup and restore tests | A backup that has never been restored is an assumption. Identity data includes users, clients, realms and keys, and restoring it into a clean environment is the real test. | Ask for a documented restore test with timings, the restored scope, the person who ran it and the date. Confirm backups are encrypted and stored outside the failure domain. |
| Upgrade cadence and staging tests | Keycloak plans four minor releases a year and a major release every two to three years, and says breaking changes in a minor release will be opt-in. Upgrades still need a staging copy of production data and a rollback plan. | Ask for the upgrade calendar and the staging test scope, including login flows for each protocol. For Keycloak Operator installs, confirm the update approval mode is set to manual, as the Operator documentation strongly recommends. |
| Security release handling | For authentik, supported security fixes apply to the 2026.5.x and 2026.8.x version lines, and security releases are announced at least 24 hours in advance. Teams need time to schedule a patch window. | Confirm which version lines are in support at the time of go-live and who receives the advance notice. Ask how the team will receive notices and how quickly a patch will be applied. |
| Database schema migration method | Keycloak migrates its schema automatically at startup by default. Large deployments may prefer manual SQL migration applied by administrators, which changes who reviews each change. | Ask which migration method is configured and who approves the SQL. Confirm that a schema change is tested in staging before production. |
| Monitoring and metrics | Login failures, token errors, cluster health and database connection use show problems before users report them. Logs and metrics also feed the audit trail that compliance reviewers ask for. | Ask for the list of metrics exposed and the alerts defined on them. Confirm that authentication logs are forwarded to the central log platform with retention that matches policy. |
| Administrator roles and runbooks | Realm and administrator changes are high-impact. Named roles, approval steps and written runbooks for common incidents prevent one person from being the only operator. | Request the role matrix, the runbook list (for example, certificate rotation, node restart, realm restore) and evidence of the last runbook exercise. |
| Support hours and vendor support windows | Community releases and commercial support differ in response times, coverage and end-of-support dates. Confirm which version your partner will support and for how long before planning upgrades. | Confirm support hours, escalation paths and the end-of-support date for the chosen version with the vendor or the distribution provider. Request these in writing as part of the quote scope. |
Which applications cannot do SSO at all, and what to decide for them
Build the exceptions list before the rollout date is set, because every application that cannot speak SAML or OIDC will otherwise surface during cutover. Start with an inventory that marks each application as one of a few types: web apps with no federation support, desktop clients, thick clients that authenticate straight against a database, network appliances and firewalls with local admin accounts, shared accounts, and service accounts that run jobs or connect between systems. Ask each application owner to confirm the protocols the vendor actually supports in the version you run, not the version on the vendor's marketing page. Shared and service accounts need a separate column, because a person-facing SSO decision does not fit them and they are often the hardest to retire.
For each exception, choose one of four options and record why. An identity-aware proxy or header-based gateway can place a login in front of a web app that trusts a user header, and authentik documents proxy and remote access control (RAC) provider types that cover some of these cases; confirm with the vendor and your own testing whether the application accepts the forwarded identity safely. LDAP or Kerberos binding works only where the application has a directory setting, and it usually needs a bind account and a decision on password storage. A local account with a password held in a secrets manager is the fallback for appliances and legacy clients, and it needs a rotation schedule and check-out logging. Retirement is often the cheapest answer for applications nobody uses.
Give every exception a named owner and a review date, and set the review interval according to the risk of the application, not the convenience of the team. Record the compensating controls, such as network restriction, session recording or MFA at the jump host, and have the owner sign them. Ask your implementation partner to show how the exceptions register is kept current during onboarding and offboarding, and confirm that the identity provider's audit logs can still show who used a shared or local account. An exception without an owner or a date tends to stay in production for years, and auditors will ask for it.
Questions buyers ask about SSO requirements and effort
How long does an SSO requirements workshop take?
The length depends on how many applications are in scope, how many directories need to be federated and how many applications have unusual login flows. A workshop covering a short, well-documented application list can be finished in a few sessions, while estate-wide scope with legacy systems needs more time for owners to answer. Ask the implementation partner to state in writing which sessions, which people and which deliverables are included before work starts. Duration is a scope question, so it should appear in the fixed-scope agreement rather than in a general estimate.
What drives the cost of an SSO rollout?
Cost is driven by the number of applications to integrate, the protocol mix (SAML, OIDC, LDAP, or none), the number of directories to federate, the MFA and passkey rollout, and the length of the exceptions list. Applications that support SAML or OIDC are usually simpler than legacy systems that need a proxy, a custom connector or a manual workaround. Infrastructure, database, support and any paid edition of the software are separate recurring costs. For a full breakdown of who is paid for what, see the SSO cost page on this site.
Can our team write the SSO requirements checklist ourselves?
Yes, many internal teams can draft the checklist, provided they collect the right inputs from application owners and the directory team. The checklist needs a list of applications with their protocols, the directories and user populations, the MFA and session rules required by your regulators or policies, provisioning and deprovisioning expectations, and a documented list of applications that cannot use SSO. Internal teams often find the exceptions list is the hardest part because it requires owners to confirm what their software actually supports. An implementation partner can review the draft and turn it into a written scope.
What does the SSO work need from application owners and the directory team?
Application owners need to confirm the login protocol each application supports, the attributes and roles it expects, the test environment available for integration and who signs off on cutover. The directory team needs to provide read access or a service account to the source directories, confirm naming and group structures, and agree how joiners, movers and leavers will flow into the identity provider. Both groups should name a decision-maker who can approve changes during the rollout. Make these responsibilities explicit in the scope so delays are visible early.
How do we choose between Keycloak, authentik, ZITADEL and FreeIPA?
The choice depends on the protocols you need, the directories you already run, the operational skills in your team and your licensing constraints. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0 along with LDAP and Active Directory federation. authentik is licensed under MIT for most of its code, with an enterprise directory under a separate license, so check which features you need against the authentik licensing terms and the authentik pricing page. ZITADEL is licensed under AGPL-3.0 and supports multi-tenancy. FreeIPA is usually considered where Kerberos and Linux identity are central. Run a short proof of concept against your top applications before deciding.
What should we ask a partner to include in a fixed-scope SSO quote?
Ask the partner to list every application in scope, the protocol each one uses, the directories to federate, the MFA and passkey policy to implement, the provisioning and deprovisioning flows, the high availability design and the audit logging to be delivered. The quote should also name the environments, the testing and cutover steps, the training and documentation, and what is excluded, such as legacy applications or ongoing support. DeployOpen works from a written scope, and a quote follows from that scope. Ask for each deliverable and acceptance criterion in writing, and confirm how changes to scope are priced.
Which applications are most likely to delay an SSO rollout?
Applications without SAML or OIDC support, desktop clients, thick-client apps that authenticate against a local directory, and systems with hard-coded service accounts are the most common sources of delay. Each one needs a documented workaround, such as a reverse proxy, LDAP bind, custom connector or a decision to retire or keep it outside SSO. Put these on an exceptions list early, with an owner and a review date, so they do not block the main cutover. Confirm each exception with the application vendor where possible, because support statements change between versions.
How DeployOpen scopes SSO requirements and delivers the rollout
DeployOpen starts by writing down the protocols, directories, MFA rules and exceptions for your workforce login, then agrees that scope in writing before any build work begins. We plan, implement, customize, integrate, harden, document and support the self-hosted identity platform inside your own infrastructure.
How we scope
- We inventory every application and record whether it needs SAML, OIDC, LDAP, or a proxy-based approach.
- We map the directories to federate, the MFA and passkey policy per user group, and the session rules for each application.
- We agree the written scope, deliverables and timeline with you before work starts, and list applications that cannot do SSO as separate items.
How we build
- We deploy the chosen platform in your cloud accounts, data centers or air-gapped network, including the database and high availability design.
- We configure realms or organizations, clients, identity brokering, provisioning connectors and branding to match the agreed requirements.
- We test login, MFA enrollment, deprovisioning and failover against the documented requirements before any user is moved.
How we hand over
- We document the configuration, the requirements traceability, the access and audit logging setup, and the runbooks your team needs.
- We produce configuration exports and evidence that your internal or external assessors can review for control requirements you choose to cover.
- We walk your administrators through daily operations, upgrade steps and the process for changing policies after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer that follows the agreed scope.
- Upgrades are planned and tested in a non-production environment before the production change window.
- We confirm with you, in writing, which platform versions, patch cadence and response expectations apply before the retainer starts.
