AD FS vs Keycloak: which fits your federation estate
Keep AD FS if most of your relying parties are WS-Federation applications and your farm is run by a Windows team. Choose Keycloak if your estate is mostly OpenID Connect and SAML, you can operate Linux, and you want an Apache 2.0 licensed server with no Windows Server dependency. Most organizations land somewhere in between, so the work is to count your relying parties by protocol before you decide anything. AD FS fits when your estate depends on WS-Federation for applications such as SharePoint, when claim rules are maintained by Windows administrators, and when federation sits inside a farm that already receives Windows Server patching and certificate management. Keycloak fits when your applications already speak OIDC or SAML, when your platform team runs Linux and containers, and when you want the server licensed under Apache 2.0 with the Keycloak Operator available for Kubernetes deployments.
The two products also differ in how they are built. AD FS uses claim rules on each relying party trust, while Keycloak uses protocol mappers attached to clients, so each translation has to be re-expressed and tested rather than copied. Keycloak federates existing LDAP and Active Directory users, which lets you keep your directory in place, but it does not serve WS-Federation, so any Kerberos or WS-Federation dependency needs its own plan. Operations differ too: a Keycloak cluster needs a supported database such as PostgreSQL, a synchronously replicated database for high availability, and a team that handles upgrades, with the Operator's manual approval mode recommended for updates. Confirm each of these against your environment before you commit.
The decision turns on four questions. First, how many relying parties depend on WS-Federation, and can they move to OIDC or SAML? Second, do you need Kerberos integrated sign-in for domain-joined clients, and who will operate that path? Third, does your team have the Linux, database and identity operations skill to run Keycloak after go-live? Fourth, is Entra ID a viable destination, given that Microsoft recommends moving off AD FS? If Entra ID is possible for some applications, use the answer to split the estate. Keycloak is strongest when the answer to the first and third questions is favorable and federation must stay on your own infrastructure.
Which option fits which scenario
This table maps common AD FS estate conditions to the better fit, Keycloak or a different option, and the condition that drives the choice. Read each row against your own relying parties, Active Directory layout and network constraints before deciding.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| WS-Federation apps such as SharePoint | Keep AD FS or move to WSO2 Identity Server | Keycloak's documented client protocols are OpenID Connect and SAML, so WS-Federation relying parties need a plan before any cutover |
| OIDC and SAML SaaS apps | Keycloak | Both protocols are documented and supported, so the work is re-creating clients and translating claim rules into mappers |
| Kerberos-dependent or Windows-integrated apps | Keep AD FS or add a Kerberos-capable layer | Confirm how each app authenticates today, since Keycloak's Active Directory federation does not by itself replace Windows integrated authentication for every app |
| Linux-first teams with existing Active Directory | Keycloak | Keycloak runs on Linux with a supported production database and federates LDAP and Active Directory users, so the directory can stay in place |
| Air-gapped or isolated networks | Keycloak, deployed inside the isolated network | Plan the database, container images or packages, certificates and patching sources in advance, since no external service is reached at runtime |
| Multi-site high availability | Keycloak with a documented HA architecture | Both supported designs need a synchronously replicated database, so confirm latency and replication capacity between sites before choosing the design |
| Teams that need an on-premises Windows-native farm with minimal change | Keep AD FS until a planned exit | The farm and proxy model is familiar to Windows operators, and the migration effort is justified only when the relying party inventory is complete |
How claim rules map to Keycloak protocol mappers
AD FS issues claims through claim rules attached to each relying party trust, while Keycloak issues them through clients, protocol mappers and, where users come from elsewhere, identity brokering. The practical consequence is that a single AD FS trust often bundles several things at once: which claims are sent, how they are computed from Active Directory attributes, which issuance transform rules apply, and how the relying party's signing and encryption certificates are configured. In Keycloak these concerns are split. A client holds the redirect URIs, protocol and signing settings, a mapper produces each claim, and realm-level settings govern the rest. Expect the translation work to be real and iterative, not a mechanical copy. Start by exporting the claim rules for each trust and listing every outgoing claim type, its source attribute and any transformation such as a regular expression, a conditional or a join, so you can see which mapper types will cover each one and which will need a custom approach.
Behavior differs in ways that matter to relying parties. Claim names and formats, such as the SAML attribute names, name identifier format and the way group membership is expressed, may need to match what the application already expects. Multi-valued attributes, empty values and the order of claims can change between the two products, and token lifetimes and session handling are configured in different places. Keycloak's group and role mappers do not automatically reproduce every AD FS group logic, so confirm the membership an application relies on for authorization against a test user before cutover. Confirm these details with the Keycloak documentation for your version and with each application owner, rather than assuming a default matches.
Test each relying party on its own. Build a test matrix for every trust that covers sign-in, the exact token or assertion contents, authorization outcomes for users in each group, logout behavior and failure cases such as a disabled account. Compare decoded tokens and SAML assertions from AD FS and Keycloak side by side, and keep the results as evidence for the change record. Plan for a parallel run period where both identity providers can serve the same application, and for rollback. Relying parties that depend on WS-Federation cannot be moved this way, so identify them during the inventory step before you commit to a sequence.
Where identity data and control sit under each option
AD FS and Keycloak put identity data in different places and assign operational control to different teams. The cards below cover where the data lives, who runs the database and patching, and which assessment evidence each option produces.
AD FS and WAP on Windows Server
AD FS runs as a federation server role on Windows Server, and Web Application Proxy runs as a separate, internet-facing server role. Both depend on Active Directory for user data and on Windows patching cycles for their own servers. Check where each farm and proxy node sits, which network zone the proxies occupy, and whether your Windows Server licensing and patch process covers every node.
Keycloak on your own Linux hosts
Keycloak runs on Linux in your data center, your cloud account or an air-gapped network, and it stores realm data in a database you select. Because the deployment is yours, you decide the host image, the network placement and the patch schedule. Confirm that your Linux and container platform teams can operate the chosen topology.
Supported database and data location
Keycloak's supported production databases include PostgreSQL 14 to 18, MySQL, MariaDB, Microsoft SQL Server, Oracle Database and Azure SQL, and the development file database is not for production. The database holds the identity data, so its residency, encryption, backups and access controls define where your identity data sits. Ask which database engine your DBA team already supports and who owns its backups.
Red Hat build of Keycloak support
Red Hat build of Keycloak is Red Hat's supported distribution of the open source Keycloak project and replaces Red Hat Single Sign-On. If your organization needs a vendor-backed support contract and a supported build for regulated workloads, this distribution is the option to price against the community release. Confirm the supported versions, support lifecycle and terms directly with Red Hat before you commit.
Compliance evidence and audit scope
A self-hosted identity platform changes which controls your auditor tests, because you now own configuration, access reviews, logging and change records that AD FS and Entra ID partly provide. DeployOpen can prepare the systems, controls and evidence for a compliance assessment, but it does not issue audit reports, attestations or certifications. Ask your independent auditor which evidence they will require before the migration starts.
Farm and proxy architecture versus Keycloak clusters
In an AD FS deployment, federation servers form a farm that shares one configuration store. One primary node makes configuration changes, and secondary nodes serve sign-ins. Web Application Proxy servers sit in the perimeter network and relay external requests to the internal farm, so the design has two tiers that operators maintain separately. A load balancer typically sits in front of both tiers, and certificates, service accounts and patching apply to each server.
- Two tiers to operate: Federation servers hold trust and claim configuration, while Web Application Proxy servers handle external traffic and need their own patching and certificate renewal.
- Shared configuration store: The farm keeps its configuration in one store, either the Windows Internal Database or SQL Server, so that choice shapes failover and backup planning.
- Load balancer and endpoint names: Traffic depends on the load balancer and on the published federation service names, which must match the certificates in use.
- Primary node dependency: Configuration changes go through the primary node, so teams need to plan maintenance windows and confirm how a primary node failure is handled in their Windows Server version.
Check the current farm topology, configuration store and load balancer design in your own environment before comparing them with Keycloak, because the two-tier AD FS layout does not map one to one onto Keycloak nodes.
Keycloak runs as a set of nodes that share one database and form a cluster for session and cache state. The first documented high availability architecture is a single cluster, which can optionally be spread across availability zones. New nodes are added behind a load balancer or reverse proxy that your team provides, and every node points at the same database. The main failure domains are therefore the database, the network between zones and the load balancer, and the team's own design choices decide how those are protected.
- One cluster, many nodes: All nodes serve sign-ins from the same realm configuration and share one database.
- Optional zone spread: The cluster can span availability zones, which helps withstand a zone outage if the latency between zones suits the design.
- Traffic entry point: The load balancer or reverse proxy is part of your build, so there is no default equivalent of the AD FS Web Application Proxy tier to deploy.
- Synchronous database requirement: The database must be replicated synchronously for this design, which makes database high availability a central part of the plan.
Confirm which cluster and cache settings apply to your Keycloak version in the Keycloak high availability overview, and test whether the latency between your zones fits the design.
Keycloak documents two multi-cluster options in addition to the single cluster. The v2 design runs a cluster at each site without an external Infinispan deployment. The v1 design runs a separate Infinispan cluster per site and is deprecated in the documentation. Both supported designs require a synchronously replicated database, so the distance and latency between sites affect how writes are handled. AD FS farms rarely span sites in this way, so teams moving from a single AD FS farm should treat multi-site Keycloak as a separate design decision.
- Multi-cluster v2: Each site runs its own cluster, and the design does not need an external Infinispan deployment.
- Multi-cluster v1 (deprecated): Each site pairs a Keycloak cluster with a separate Infinispan cluster, and the documentation marks this design as deprecated, so new builds should avoid it.
- Synchronous replication across sites: Both supported designs depend on synchronous replication, so inter-site latency shapes the write path and the user experience.
- Failover testing: Site failover needs test runs against your own load balancer, DNS records and client redirect URIs, not only a review of configuration files.
Ask your platform team or the vendor to confirm the current status of each multi-site design for your release before choosing one.
Keycloak's supported production databases include MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL 14 to 18, EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL. The default dev-file database is intended for development only. Keycloak migrates its schema automatically at startup by default, and large deployments can apply the SQL manually under change control. The database is the component most cluster designs depend on, so its engine, replication and capacity should be settled before the node count.
- Supported production engines: Choose from the listed engines, and check that the engine version falls within the range the Keycloak documentation supports for your release.
- Synchronous replication mode: Whichever engine you select, configure synchronous replication for the supported cluster designs.
- Schema migration approach: Automatic migration at startup is the default, while manual SQL migration suits large deployments that need review before each change.
- Sizing inputs: Estimate capacity from your own user count, sign-in volume, session lifetimes and number of clients, then load test the design before go-live, since no generic sizing figure applies to every estate.
- Operator update control: If you run the Keycloak Operator on Kubernetes, the documentation strongly recommends manual approval mode for operator updates to avoid unintended upgrades.
Ask the platform team to confirm the database engine version, replication mode and load test results in writing before committing to a topology. The Keycloak database guide lists the current supported engines.
What moving from AD FS to Keycloak involves
The sequence turns a farm of AD FS trusts into Keycloak clients and user federation over the existing directory, with each application tested before the farm is switched off.
Inventory every relying party trust
Before any build work, list each AD FS relying party trust, its protocol (SAML, WS-Federation or OpenID Connect), the claim rules it depends on, its signing and encryption certificates, and whether anyone still signs in through it. Export the trust settings and check actual sign-in activity rather than relying on the trust list alone. The team that owns each application confirms its business owner and test contact. The output is a migration register with one row per application and a planned cutover order. Ask your team to confirm which records they can export from the farm, since the exact method depends on your AD FS version and configuration.
Connect Keycloak to Active Directory
Install Keycloak on the target platform, configure a production database, and set up a user federation provider that reads the existing Active Directory through LDAP. Map the attributes that applications need, such as the username, email and group membership, and decide whether Keycloak imports users or reads them on demand. Keycloak's built-in user federation supports existing LDAP and Active Directory servers, but Kerberos single sign-on for domain-joined clients needs separate configuration and testing. The step is complete when a test user from the directory can authenticate to the Keycloak admin console and a test client, with group membership visible to the mappers.
Re-create SAML and OpenID Connect clients
For each SAML or OIDC relying party in the register, create a matching Keycloak client with the same entity ID or redirect URIs, signing certificates, and allowed attributes. Keycloak documents its SSO protocols as OpenID Connect and SAML, so these applications move first. Keep the old AD FS trust active during this work, so every new client is validated separately. The step closes when each client's metadata has been reviewed against the original trust and the application owner has confirmed the expected login behavior on a non-production address.
Translate claim rules into mappers
Walk through each AD FS issuance and transformation rule and record the claim it produces, the source attribute and any conditions. Rebuild those rules as Keycloak protocol mappers and client scopes so the same name identifier, roles and group claims reach the application. Rules with conditional logic or custom code often need a design decision, and the application owner should approve any change in claim content. The output is a mapping table showing each AD FS rule beside its Keycloak mapper, plus a note for every rule that could not be reproduced exactly.
Decide how to handle WS-Federation applications
The Keycloak SSO protocols chapter documents OpenID Connect, SAML and Docker registry authentication, and does not list WS-Federation among its client protocols. Identify every application that relies on WS-Federation, such as older SharePoint or line-of-business apps, and decide whether each one moves to SAML or OIDC, is replaced, or needs a different product. Confirm with the application vendor whether a SAML or OIDC option exists. The step is complete when each WS-Federation app has a named path and an owner. For products that need WS-Federation, the sibling pages on authentik and WSO2 Identity Server cover that protocol.
Test each application and sign off
Test every migrated application in a staging environment with real test accounts from each group that uses it. Check single sign-on, logout, session lifetime, claim values, certificate rotation and multi-factor prompts against the behavior recorded on the AD FS side. Run failure tests, including a sign-in attempt with a disabled account and a token with an unexpected claim. The step closes when the application owner signs off in writing, and each record in the migration register shows its test date and result.
Cut over and retire the AD FS farm
Move applications in the planned order, changing DNS, redirect URIs or relying party references as each one switches. Keep a rollback path to the AD FS trust for each application until its owner has accepted production use over an agreed period. Once every application has moved, disable the trusts, remove the Web Application Proxy publications, and document how the Web Application Proxy replacement and the AD FS certificates and service accounts were retired. The step is complete when the farm has no active trusts, the register is closed, and the decommissioning record is filed with your audit evidence.
Questions buyers ask before choosing Keycloak over AD FS
Is Keycloak cheaper than AD FS to run on premises?
Keycloak's software is free under the Apache License 2.0, so the cost difference comes from what surrounds the software. AD FS costs include Windows Server licenses and client access licenses for the federation and Web Application Proxy servers, plus SQL Server if the farm is large. Keycloak costs include Linux servers, a supported production database such as PostgreSQL, load balancing, and staff time to operate it. Optional support subscriptions from Red Hat or others are a recurring line item you choose to add. Ask any provider for a written breakdown that separates one-time migration work from recurring operations and licensing.
How long does an AD FS to Keycloak move take?
The duration depends on how many relying party trusts you have, how many use WS-Federation, how much claim rule logic must be rebuilt as mappers, and how many application owners must test. No duration figure is supplied here, so ask for a timeline tied to a named inventory of relying parties in the written scope. A fixed-scope engagement at DeployOpen starts with agreed scope, deliverables and timelines in writing before work begins. Use the inventory of trusts and their usage to size the work honestly.
What does my team need to provide for a Keycloak project?
You need named owners for each application, access to the AD FS configuration and relying party trust exports, and an Active Directory service account for LDAP or Kerberos federation. You also need people who can approve certificate and redirect URI changes, and a change window for cutover. Security and compliance staff should review the claim mapping and MFA policy. Ask the provider to list these dependencies in the scope so gaps are visible before work starts, not during cutover.
Can our own team run Keycloak after the migration?
Yes, if your team has Linux, database and identity skills and a clear on-call model. Keycloak runs as a server with a database, and the high availability designs require a synchronously replicated database. Routine work includes monitoring through the documented metrics, applying updates, and backups, which Keycloak's export and import commands do not replace as a full backup and restore mechanism. Ask for a written runbook and a handover plan before deciding who operates it.
Is Keycloak licensed and supported like a commercial product?
Keycloak is open source under the Apache License 2.0 and is a Cloud Native Computing Foundation incubating project, so you can use it without a license fee. Community support is available through the project. Red Hat build of Keycloak is Red Hat's supported distribution based on the open source project and replaces Red Hat Single Sign-On. Confirm with the vendor which support terms, lifecycle and certifications apply to the version you plan to run.
How often does Keycloak release, and how do upgrades work?
Since Keycloak 26.0, the project plans four minor releases a year and a major release every two to three years, and breaking changes in a minor release are opt-in. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Keycloak migrates its database schema automatically at startup by default, but the upgrading guide suggests manual migration for large deployments. Plan a test environment and a regular upgrade window into your operating model.
If we move to Entra ID, do we still need Keycloak?
Microsoft's recommended exit from AD FS is Entra ID, and that is the right first question to answer for your estate. Keycloak fits when federation must stay on premises, in country or inside an isolated network, or when applications need protocols or features you cannot place in Entra ID. Decide per application group rather than for the whole estate. Ask your Microsoft account team and your security office to confirm which relying parties can move to Entra ID and which must remain on a self-hosted service.
What drives cost on each side of the switch
The AD FS side of the cost comparison is mostly licensing and labor tied to Windows. Each federation server and each Web Application Proxy server in the farm runs on a Windows Server license, and the client access licenses that go with it depend on how your organization is licensed for Windows Server. Larger farms also need a SQL Server database for the configuration store, which adds a database license and a database administrator's time on top of the Windows estate. Certificate management for the token-signing and service communications certificates, plus monthly patching of every farm and proxy node, recurs every year whether or not any applications change. Ask your Microsoft licensing partner or reseller to price the exact Windows Server editions, CALs and any SQL Server licenses against your current agreement, because these depend on your enrollment and existing entitlements, not on a list price.
The Keycloak side has a different shape. The Apache License 2.0 that covers the project costs nothing to obtain, so the spend is in the infrastructure and the people who run it: Linux hosts or Kubernetes capacity for at least two nodes, a supported production database from the list in the Keycloak database guide, load balancing, monitoring, and backups. Those are largely recurring costs, and they grow with the number of nodes, the database size and the level of high availability you choose. The main one-time cost is migration work: rebuilding each relying party as a SAML or OpenID Connect client, translating claim rules into mappers, and testing each application. Be clear with your team that the community project is not the same as a supported distribution. Red Hat build of Keycloak is a supported product based on the open source project, and it carries a subscription that covers vendor support and maintenance. If your auditors or application owners expect a named support contact, budget for that subscription and request its quote from Red Hat or a reseller. Otherwise, you carry that support load in-house or through a retainer.
When you ask for quotes, make each vendor or partner split the figures into one-time work (inventory, design, migration, testing, cutover) and recurring work (licenses, support, patching, certificate renewal, on-call operations). Ask for the assumptions behind each line, including the number of relying parties, the number of WS-Federation applications that will need a different path, and whether the Windows Server licensing is already covered by an enterprise agreement. Those three factors move the comparison more than any product price, so confirm them against your own environment before you compare totals.
How DeployOpen helps you evaluate and move off AD FS
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a move from AD FS to Keycloak can be scoped against your actual relying parties and Active Directory before any work starts. Engagements are fixed-scope, with deliverables and timelines agreed in writing first.
How we scope
- Inventory every AD FS relying party trust, its protocol, claim rules and certificates against your current usage data.
- Classify SAML, OpenID Connect and WS-Federation applications, and flag any WS-Federation app Keycloak does not serve.
- Agree the written scope, deliverables and timeline with you before any build work begins.
How we build
- Re-create SAML and OpenID Connect clients in Keycloak and translate AD FS claim rules into protocol mappers.
- Connect Keycloak to your existing Active Directory through LDAP user federation and confirm Kerberos behavior.
- Test each relying party in a staging realm, including MFA flows, logout and certificate rotation, before cutover.
How we hand over
- Document the relying party inventory, client configuration, mapper logic and cutover runbook for your team.
- Set up backup and restore procedures, noting that realm export and import have documented limitations and require stopped nodes.
- Provide evidence and control documentation for your compliance team; independent auditors perform any assessment.
How we support
- Plan Keycloak upgrades with your team, using the project's release cadence and opt-in breaking change policy.
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover.
- Ask us to confirm version-specific details, licensing and support terms against the current vendor documentation before you commit.
