Keycloak vs FreeIPA: when each one is the right choice
Choose Keycloak when the main problem is web single sign-on for applications that speak OpenID Connect, OAuth 2.0 or SAML 2.0. Choose FreeIPA when the main problem is Linux and UNIX identity: users, groups, host enrollment, Kerberos tickets, host-based access rules and an internal certificate authority. FreeIPA's own documentation describes it as an integrated identity and authentication solution for Linux and UNIX networks, combining 389 Directory Server, MIT Kerberos, the Dogtag certificate system and SSSD on clients. It is not a web SSO server, and Keycloak is not a Kerberos domain controller for servers. The decision turns on three questions: which protocols your applications speak, which hosts need Kerberos and host-based policy, and which team will operate the platform day to day.
Start with the applications. If most of them are web apps, SaaS integrations or APIs that expect OIDC or SAML, Keycloak is the direct fit, and it can also federate users from an existing LDAP or Active Directory directory. If the estate is mostly Linux servers, bastion hosts and internal services that authenticate with Kerberos or need per-host sudo and HBAC rules, FreeIPA covers those needs in one product. Then check the hosts. Ask whether any server needs kinit-style Kerberos login, certificates issued to hosts, or access rules tied to host groups. If yes, FreeIPA belongs in the design even when Keycloak handles the web tier.
The two are often combined. A common pattern is to keep FreeIPA as the user and host source of truth and connect Keycloak to it through LDAP user federation, so web logins use the same accounts as Linux logins. Confirm during design which side owns passwords, MFA enrollment and account lockout, because FreeIPA's OTP support and Keycloak's MFA settings can both apply to the same user. Also confirm your team can run both: FreeIPA needs dedicated replicas, and its backup guidance warns that restoring an outdated backup into an active replica topology can break replication. Keycloak needs a supported production database and a clear upgrade process. Name an owner for each before you pick.
Which platform fits which scenario
This table maps common scenarios to the platform that fits best, with the reason tied to supplied capabilities. Read each row by asking which protocols and directory services the workload needs, then check the combined row if you run both web applications and Linux hosts.
| Scenario | Better fit | Why |
|---|---|---|
| SSO for SaaS-style web apps using OIDC or OAuth 2.0 | Keycloak | Keycloak provides OpenID Connect and OAuth 2.0 single sign-on, which is the protocol set modern web and API applications expect. |
| SSO for internal apps that require SAML 2.0 | Keycloak | Keycloak supports SAML 2.0 alongside OIDC. FreeIPA's Kerberos KDC does not serve SAML applications, so SAML SSO is outside its design. |
| Linux server login, host groups and sudo policy | FreeIPA | FreeIPA's 389 Directory Server stores hosts, users and policies, and SSSD on clients applies them. Keycloak does not manage Linux host policy. |
| Kerberos tickets for services and single sign-on on Linux desktops | FreeIPA | FreeIPA bundles an MIT Kerberos KDC for single sign-on, so Kerberos authentication for services comes built in. |
| Issuing and renewing certificates for hosts and services | FreeIPA | FreeIPA includes the Dogtag certificate authority. Keycloak does not issue certificates for hosts, so confirm any requirement for a Keycloak-issued TLS role before relying on it. |
| Mixed estate with Active Directory users reaching Linux resources | FreeIPA | FreeIPA can establish a cross-forest trust with an AD domain on Windows Server 2008 R2 or later. Confirm the DNS domain naming rule before planning the trust. |
| Both web SSO and Linux host identity are required | Keycloak and FreeIPA together | Use FreeIPA as the user and host source and federate Keycloak to it through LDAP. Keycloak then serves OIDC and SAML to applications while FreeIPA keeps accounts, Kerberos and host policy. |
How each platform is built and what that means for operations
Keycloak is one server application with a database behind it, while FreeIPA is a bundle of directory, Kerberos, certificate authority and DNS services that must be deployed and replicated together. The cards below set out what each component asks of the team that runs it, so you can match the operating load to the people you have.
Keycloak needs a production database
Keycloak stores its realms, clients and users in a relational database, and the default dev-file database is for development only. The Keycloak database guide lists the supported engines, including PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL. A small team should confirm which engine it can back up and patch, because the database becomes the system of record for every login. Ask who owns that database before you commit to Keycloak.
Keycloak high availability designs
Keycloak documents a single cluster that can span availability zones, a multi-cluster v2 design without an external Infinispan cluster, and a deprecated multi-cluster v1 design. Both supported designs depend on a synchronously replicated database, so the database topology drives the Keycloak topology. A platform team can plan for this from the start. A small team should expect to run one cluster and confirm that its database can meet the replication requirement before going further.
Keycloak Operator on Kubernetes
On Kubernetes or OpenShift, the Keycloak Operator manages Keycloak and realm and client custom resources. It is installed through the Operator Lifecycle Manager, which Keycloak recommends, or with kubectl. The operator documentation strongly recommends manual approval mode for updates, so upgrades remain a planned change rather than an automatic one. Teams without Kubernetes skills should weigh whether they can run the cluster, the operator and the external database together.
FreeIPA bundles several services
FreeIPA combines 389 Directory Server for LDAP, an MIT Kerberos KDC, a Dogtag certificate authority, SSSD on enrolled clients, and optional ISC BIND DNS and NTP. Because these services share one deployment, you upgrade, back up and troubleshoot them as a unit. A small team gets a single product to learn, but it must understand Kerberos, certificates and DNS well enough to diagnose failures across all of them.
FreeIPA multi-master replication
FreeIPA replicates directory data among multi-master servers. The deployment recommendations advise at least two to three replicas in each datacenter, no more than four replication agreements per replica, and dedicated servers without other applications. Replicas that run the certificate authority or DNS need placement planning in every site. A platform team should design the topology on paper before the first enrollment, and a small team should treat replica count as a fixed cost to budget for.
FreeIPA backup and restore
FreeIPA provides ipa-backup and ipa-restore, with full backups or online data-only backups. The backup documentation warns that the first server handles certificate renewal and CRL publication by default, and that restoring an outdated backup into an active replica topology can break replication. Test restores in a lab before you rely on them, and write a runbook that names which server is first. This is a recurring discipline that Keycloak operators also need for their external database.
Capabilities side by side: protocols, identity integration and server management
This table compares what each platform does natively for applications, Linux hosts and directory integration. Read each row as a question about your estate: if your main need is web SSO for applications, the protocol rows matter most; if it is Linux logins, Kerberos and host policy, the FreeIPA rows matter most. Where the supplied facts do not settle a point, the cell tells you what to confirm.
| Capability | Keycloak | FreeIPA |
|---|---|---|
| OIDC, OAuth 2.0 and SAML 2.0 | Native support for OpenID Connect, OAuth 2.0 and SAML 2.0 for web and API applications | Not a web SSO protocol server; application sign-on is handled through Kerberos and LDAP, so confirm any OIDC or SAML need with the vendor |
| Single sign-on mechanism | Browser-based SSO through OIDC and SAML sessions | Kerberos single sign-on through an MIT Kerberos KDC for domain-joined Linux clients and services |
| Directory and user store | Reads users from LDAP or Active Directory through user federation; can also be configured as a standalone user store | Built on 389 Directory Server as a multi-master LDAPv3 directory for users, groups, hosts and policies |
| Certificates | Not a certificate authority; certificates are handled outside Keycloak | Integrated Dogtag certificate authority, with random certificate serial numbers by default since 4.13.0 |
| Host, sudo and access policy | Not a host policy engine; application roles and authorization services are its scope | Host-based access control (HBAC) rules and sudo rules managed centrally, with SSSD on clients; sudo and HBAC migration requires manual LDIF work |
| Two-factor authentication | Supports MFA through its authentication flows; confirm the specific factors and their configuration in the current server administration guide | HOTP (RFC 4226) and TOTP (RFC 6238) tokens, including hardware tokens such as YubiKeys, and can proxy OTP checks to an existing RADIUS server |
| Identity brokering to external providers | Brokers logins to external OIDC or SAML identity providers | Cross-forest trust with an Active Directory domain on Windows Server 2008 R2 or later, so AD users reach Linux resources; the IPA DNS domain must not overlap any AD forest domain |
| Database and replication design | Needs a relational database in production (PostgreSQL 14 to 18, MariaDB, MySQL, SQL Server, Oracle or Aurora PostgreSQL) and a synchronously replicated database for HA designs | Multi-master replication between FreeIPA servers; the deployment guidance advises two to three replicas per datacenter and no more than four replication agreements per replica |
| Server management and upgrades | Kubernetes Operator installed through OLM or kubectl, or the server distribution on virtual machines; minor releases can carry opt-in breaking changes | Packaged in Fedora, Debian, CentOS and Red Hat Enterprise Linux as Identity Management; backup and restore use ipa-backup and ipa-restore |
Licensing and editions: what is free and what is paid
Keycloak is licensed under Apache-2.0, and the upstream project does not offer a paid edition of the server. The project describes itself as a Cloud Native Computing Foundation incubating project, which reflects its governance stage rather than a support commitment. Production support for Keycloak comes either from the upstream community or from a commercial distribution, and the distribution is the main paid option.
- Apache-2.0 license: You can run, modify and redistribute the upstream server without a license fee from the project. Have counsel confirm what your own modifications and redistribution require, because the license text governs.
- CNCF incubating status: This tells you where the project sits in the foundation's maturity process. It does not promise response times, patch windows or a support contract.
- Release cadence: Since Keycloak 26.0, the project plans four minor releases a year and a major release every two to three years. Breaking changes in a minor release are opt-in, according to the project's release updates post.
- Red Hat build of Keycloak: This is Red Hat's supported distribution based on the open source project, and it replaces Red Hat Single Sign-On. It is a separate product with its own subscription terms.
Confirm which release line your team will run, how long each line receives fixes, and whether your patching process can absorb four minor releases a year.
FreeIPA is licensed under GPL-3.0-or-later and is a community project with no paid edition of its own. Every capability in the project applies to every installation, so there is no feature-gated tier to compare against. What you pay for depends on which distribution packages FreeIPA for you and whether you buy support for it.
- GPL-3.0-or-later: Copyleft obligations apply when you distribute modified versions. Confirm with counsel how the license applies to your internal use and any changes you make.
- No paid edition: The project does not sell a higher tier. The features described on the project's About page are the same whether you run community packages or a supported distribution.
- Distribution packaging: FreeIPA is packaged in Fedora, Debian and CentOS, and in Red Hat Enterprise Linux as Identity Management. Each package set follows its distribution's own release and update policy, so the version you receive may differ from the upstream line.
- Upstream tags: The newest tag in the upstream repository is release-4-13-4. The 4.13.4 release notes describe a stabilization release dated July 9, 2026, which fixed two CVEs. Track upstream releases and your distribution's updates separately.
Confirm which FreeIPA version your distribution ships, who issues its security updates and whether that version matches the line you tested.
Free software does not include vendor support, so a subscription changes who answers your questions and what they commit to in writing. For Keycloak, the supported route is the Red Hat build of Keycloak, which is based on the open source project. For FreeIPA on Red Hat Enterprise Linux, identity management is part of the operating system subscription. On other distributions, support usually comes from the community or from a third party. The license of the code stays the same in every case.
- Scope of coverage: Ask whether the subscription covers the operating system, the identity component, or both, and whether it covers only the packaged build. Keycloak support is tied to the Red Hat build, not to an arbitrary upstream release.
- Response commitments: Get support hours, severity definitions and response targets in a document, not in a sales conversation.
- Security fix delivery: Ask how CVE fixes reach your systems, which versions receive backports and for how long each one does.
- Third-party support: Ask whether the provider supports the exact packaged version, can reproduce issues on the distribution build, and what it does during an upgrade.
- Pricing: Request quotes from each vendor or provider against a written scope. This page does not state prices, and the figures you see should come from those documents.
Before you sign, map each support commitment against the components you actually run, including Keycloak, FreeIPA and the operating system beneath them.
What drives the running cost of each platform
The running cost of Keycloak is mostly its database and cluster nodes, while the running cost of FreeIPA is mostly its replica count and the people who understand it. Keycloak needs a relational database in production (PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL or others on the Keycloak database guide), and a high availability design also depends on a synchronously replicated database. FreeIPA's deployment recommendations call for two to three replicas in each datacenter, dedicated servers without other applications, and at least one replica per datacenter running PKI or DNS if you use those services. Ask the quote to price each replica and database instance separately, and to state whether the vendor assumes dedicated hardware or shared virtual machines.
Skills drive more of the recurring effort than hardware does. Operating Keycloak means Java runtime tuning, database administration, and the cluster and load balancer design you choose. Operating FreeIPA means Kerberos, LDAP, DNS, certificate authority management and SSSD client behavior, and a mistake in one of these can break logins across the estate. Upgrades differ too: Keycloak plans four minor releases a year and says breaking changes in a minor release are opt-in, so routine patching is frequent but usually predictable. FreeIPA ships stabilization releases such as 4.13.4, which fixed two CVEs, so security patching on the directory tier is not optional. Recurring work for both includes certificate renewal, backup testing (FreeIPA's backup guidance warns that restoring an outdated backup into an active replica topology can break replication), and on-call coverage.
Separate one-time costs from recurring ones in the quote. One-time work covers design, integration with your existing directories or applications, migration of users and policies, and hardening. For FreeIPA, that can include migrating users from another LDAP server with ipa migrate-ds, while sudo and HBAC rules need manual migration. Recurring costs cover patching, certificate and backup operations, monitoring, support subscriptions and retained engineering time. Request a written scope with named deliverables, the number of replicas or nodes and databases assumed, the Keycloak and FreeIPA versions targeted, the assumptions about existing Active Directory or LDAP directories, and the expected handover of runbooks. Any quote that does not state these assumptions cannot be compared fairly with another.
How to move identities and applications between them
This sequence moves identities and applications in a controlled order so that each step has a verified state before the next one starts, and local accounts are retired only after applications authenticate reliably through the new path.
Inventory identities, hosts and applications
Before any change, the platform owner lists every user and group in FreeIPA, every host enrolled in it, and every application that relies on Keycloak, FreeIPA or a local login. For each one, record the protocol it uses (OIDC, SAML, LDAP bind, Kerberos or SSSD), the owner, and whether it can change its login configuration. Include sudo rules and HBAC rules, since these will need manual rebuilding. The step is done when this inventory is signed off by the application owners and the security team, and every item has a named target platform.
Connect Keycloak to FreeIPA as read-only federation
In Keycloak, configure LDAP user federation against the FreeIPA directory with a bind account that has read access only, and confirm that the import mode and attribute mappings match the directory schema. Keep Keycloak from writing back to FreeIPA. Keycloak documents LDAP and Active Directory federation as a way to read existing users, so passwords remain in FreeIPA at this stage. The step is done when a test set of users can sign in to a non-production Keycloak client and group membership appears as expected in Keycloak.
Migrate users and groups where a copy is required
If the target is a new FreeIPA deployment or a separate directory, use the ipa migrate-ds command to move users and groups. The FreeIPA migration how-to notes that this command excludes Kerberos attributes, which FreeIPA regenerates, so every migrated user needs a new Kerberos key and a password reset or a controlled credential handover. Sudo and HBAC rules must be exported and imported manually through LDIF. The step is done when user counts and group memberships match the inventory and a sample of migrated accounts can log in through the new path.
Rebuild host enrollment and policy by hand
Re-enroll each Linux host into the target FreeIPA domain, check that SSSD resolves users and groups correctly, and rebuild the host-based access control and sudo rules the inventory identified. Confirm that DNS entries and the two DNS servers in each client's resolver configuration point at the intended servers. The step is done when a test account can log in to each host class, sudo behaves as the rules specify, and the host-level results are recorded in the change log.
Move applications one at a time
Register each application as a Keycloak client (OIDC client or SAML client) and rebuild its redirect URIs, signing certificates and SAML metadata for the new endpoints. Move one application at a time, starting with the lowest-risk one, and keep its previous login path available until the new path has been tested with real users. Because application metadata is rebuilt by hand, each application gets its own test plan. The step is done when each application completes sign-in, logout and role mapping through Keycloak, and the owner accepts the result.
Check replication and backup before cutover
When FreeIPA is part of the target topology, take a current backup with ipa-backup and confirm the first server handles certificate renewal and CRL publication by default. FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so do not restore an old backup over running replicas as a shortcut to recovery. Verify replication status across all replicas before and after each cutover. The step is done when replication reports healthy on every replica and a tested restore procedure has been written down for the environment.
Retire local accounts after a verified period
Once every application and host authenticates through the target path and a verification period has passed, disable local accounts that are no longer needed, remove the bind accounts and legacy LDAP connections that are unused, and update the inventory to show what is now authoritative. Keep the audit records from the migration. The step is done when the inventory shows one authoritative identity source for each user population and the change log is complete.
What implementing each involves and where projects run long
A Keycloak deployment starts with the database, because production use needs a relational database such as PostgreSQL 14 to 18 and the default dev-file database is for development only. Decide early whether the high availability design is a single cluster spread across availability zones or the multi-cluster v2 design, since both supported designs need a synchronously replicated database and that choice shapes your network and load balancer work. After that come realm and client setup, then federation mapper configuration so that LDAP or Active Directory attributes map correctly to Keycloak users and groups. On Kubernetes, confirm whether you will use the Keycloak Operator with manual approval mode for updates, which the Operator documentation strongly recommends. Plan upgrades as a tested runbook: Keycloak migrates its schema automatically at startup by default, but large deployments may prefer manual migration as the upgrading guide suggests.
A FreeIPA deployment is mostly planning before installation. Start with DNS, because clients need at least two DNS servers in resolv.conf and the IPA domain must be designed with the AD trust rule in mind. Then design the replica topology: the deployment recommendations advise at least two to three replicas in each datacenter, no more than four replication agreements per replica, and dedicated servers without other applications. Enrolling a Linux estate means agreeing on host groups, SSSD configuration and host-based access control rules before rollout, not after. Certificate policy is the other long-running decision: confirm which internal CA hierarchy you need, who approves certificate profiles, and whether the first server's default role in renewal and CRL publication fits your operations. Schedule ipa-backup runs and test ipa-restore in a lab, because restoring an outdated backup into an active replica topology can break replication.
The usual delay points are ownership, not technology. If nobody owns Active Directory or the DNS zones, trust setup and name resolution stall, and the FreeIPA IPA domain cannot be chosen safely. Undocumented application claims, such as which groups, attributes or roles each application expects in its token or SAML assertion, force rework in Keycloak mappers after go-live. Certificate chain decisions made late delay both the Keycloak TLS endpoints and the FreeIPA-issued host certificates. Finally, the DNS domain overlap rule for AD trusts is easy to miss: the IPA domain must not overlap with any domain in the AD forest, so confirm naming with the directory team before any installation. Ask DeployOpen or your own team for a written inventory of these owners and dependencies as part of scoping.
Questions buyers ask before choosing or hiring help
Can Keycloak replace FreeIPA for Linux login?
Not on its own for most Linux estates. Keycloak handles web single sign-on through OpenID Connect, OAuth 2.0 and SAML 2.0, and it can federate users from LDAP or Active Directory. FreeIPA also covers the host side: a 389 Directory Server for users, groups, hosts and policies, an MIT Kerberos KDC for single sign-on on Linux, and a Dogtag certificate authority for issuing certificates. If your requirement is Kerberos login to servers, host-based access control or certificate lifecycle, you still need something that does those jobs. Confirm with your own architects which of those host functions your servers depend on before you retire anything.
Do we need both Keycloak and FreeIPA?
Often yes, and the common pattern is to federate them. FreeIPA holds the Linux identities, groups and host policies, and Keycloak sits in front of your web applications, brokering or federating users from that directory. Keycloak's LDAP user federation can read users from an LDAP directory, so applications get one login experience while servers keep Kerberos and certificates in FreeIPA. You only need one if your estate is entirely web applications, or entirely Linux hosts with no browser-based apps. Map each application and host group to the system that owns its identity before deciding.
What drives the cost of running Keycloak and FreeIPA?
Both packages are open source with no paid edition from their upstream projects, so the cost is mostly people, infrastructure and support. One-time costs include design, integration with applications, federation setup, migration of existing users, hardening and documentation. Recurring costs include the servers and databases, backups, patching, upgrades and staff time. FreeIPA's deployment guidance calls for at least two to three replicas in each datacenter and dedicated servers, and Keycloak needs a production relational database. Ask any provider for a quote that separates one-time work from retainers, and state which hosts, applications and sites are in scope. DeployOpen does not publish a price list, and quotes follow from a written scope.
How long does an implementation take, and what changes that?
The length depends on scope, not on a fixed template. The main drivers are the number of applications to integrate, whether you federate an existing Active Directory or LDAP directory, how many FreeIPA replicas and datacenters you run, how much user and group data must migrate, and how many Kerberos or certificate workflows need to be re-tested. FreeIPA also supports migration from other LDAP servers with the ipa migrate-ds command, but sudo and HBAC rules need manual migration, which adds work. No duration is set here. Ask for a timeline in the written scope, with milestones for each integration and test cycle.
What does the work need from our own staff?
You need staff who own the identity decisions, even if a partner does the build. Expect to supply directory administrators who understand your current users and groups, application owners who can test login flows and claims, and network or DNS staff who can set resolver and time settings that FreeIPA depends on. For FreeIPA, the deployment recommendations advise at least two DNS servers in each client's resolv.conf. Someone must also own backups and restore testing, since FreeIPA's documentation warns that restoring an outdated backup into an active replica topology can break replication. Agree on who holds the admin credentials and on-call duties before work starts.
Can a small IT team run Keycloak or FreeIPA alone?
A small team can run one of them if it has Linux and identity skills and clear ownership, but running both with no outside help is a heavy load. Keycloak needs a production database, upgrade planning and a deliberate high availability design. FreeIPA needs replicas, certificate renewal and CRL publication checked, and backups tested. Keycloak's Operator documentation recommends manual approval mode for operator updates to avoid unintended upgrades, which is a process your team must follow. If you lack depth in either, a fixed-scope engagement for design and handover, followed by a retainer for upgrades and testing, is a common way to close the gap.
How does a Red Hat subscription affect the choice?
Red Hat Enterprise Linux includes Identity Management, which is FreeIPA packaged for RHEL, so a Red Hat subscription changes support and lifecycle, not the core design. Red Hat build of Keycloak is Red Hat's supported distribution of the open source Keycloak project and replaces Red Hat Single Sign-On. Whether a subscription is worth buying depends on your vendor support requirements, your audit needs and whether your staff can carry the operating load themselves. Confirm current subscription terms, supported versions and included services directly with Red Hat, because those terms are outside the facts used on this page.
How DeployOpen helps teams choose, implement or migrate
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Keycloak and FreeIPA decision is tied to your real estate, not a generic recommendation. Engagements start from a written scope with agreed deliverables and timelines, and any quote follows from that scope.
How we scope
- Map which applications need OIDC or SAML login and which servers need Kerberos, LDAP or host policy.
- Document where your user directory lives today and who owns it, including any Active Directory forest.
- Agree in writing whether Keycloak, FreeIPA, or both in a federated pattern fits each identity need.
- Confirm the target database, hosting platform and high availability expectations before any work starts.
How we build
- Deploy Keycloak in your cloud accounts, data centers or air-gapped network, with the production database you select.
- Install FreeIPA replicas with the recommended count per datacenter, with DNS and certificate authority placement planned.
- Configure the Keycloak federation or brokering link to FreeIPA and test login, group mapping and MFA end to end.
- Run security testing against the configured applications and identity endpoints before handover.
How we hand over
- Document realm, client, federation and host policy configuration so your team can audit and reproduce it.
- Set up backup and restore procedures for both the Keycloak database and FreeIPA, including replica-safe restore steps.
- Prepare control evidence and records that your internal team or an independent auditor can review later.
- Train administrators on routine tasks such as client onboarding, certificate renewal and upgrade planning.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after the initial engagement.
- Plan Keycloak and FreeIPA upgrades against each project's published release windows and your change control.
- Keep the federation link and replication topology under review as applications and user populations change.
- Confirm support terms, response expectations and the retainer scope in writing before the work begins.
