FreeIPA vs. Keycloak: Differences, Use Cases and Identity Architecture

Teams that need central accounts and access policies for Linux servers quickly encounter FreeIPA. Teams that need single sign-on for web applications are more likely to evaluate Keycloak. Both systems deal with identity and authentication, but they operate at different layers.

That makes a comparison useful even though there is no universal winner. FreeIPA organises Linux identities, hosts and host-level policies. Keycloak provides modern login protocols, sessions and application-specific claims. The real architecture question is not simply “which product?”, but “which component should own each decision?”

The short answer: they are not complete alternatives

FreeIPA and Keycloak overlap in users, groups and authentication, but that overlap does not make them interchangeable. FreeIPA is a Linux-focused identity management domain with LDAP, Kerberos, SSSD integration, hosts and policies. Keycloak is an identity provider and access management system for web applications and APIs using OpenID Connect, OAuth 2.0 and SAML 2.0.

FreeIPA on its own is appropriate when Linux hosts and their access rules are the problem. Keycloak on its own is appropriate when web SSO is required against an existing user source or Keycloak-managed users. Using both makes sense when Linux and web applications should share a controlled identity source without merging operating-system and application authorisation.

Quick decision guide

• Linux identities, hosts, SSH, HBAC and sudo: FreeIPA.
• Web applications, OIDC, SAML and single sign-on: Keycloak.
• Shared identity source for Linux and web applications: evaluate FreeIPA plus Keycloak.

What is FreeIPA?

FreeIPA combines an LDAP-based directory, Kerberos, management for users, groups, hosts and services, and optional DNS and PKI functions. Linux clients enrol into the domain and typically use SSSD. Its IPA provider understands not only identities and authentication, but also FreeIPA-specific policy such as host-based access control, central sudo rules and SELinux user maps.

• Users and POSIX groups are managed centrally instead of independently on every Linux system.
• Kerberos provides ticket-based authentication for compatible services.
• Host enrolment joins systems to the realm, directory and policy model in a controlled way.
• HBAC defines which users or groups may access which hosts and services.
• Central sudo rules delegate administrative commands to groups and host groups.
• Integrated DNS and a CA are available, but they must be deliberately fitted into the operating model.
• Replicas distribute directory, Kerberos and assigned services for availability and maintenance.

For Linux administrators this creates a consistent model: accounts, groups, SSH keys, host access and sudo permissions can be managed, automated and audited centrally. FreeIPA is therefore more than an LDAP server. It is not, however, a general-purpose OIDC or SAML identity provider for arbitrary web applications; those protocols are outside its primary architectural role.

What is Keycloak?

Keycloak is an identity and access management system for applications. It natively supports OpenID Connect, OAuth 2.0 and SAML 2.0, manages browser sessions and tokens, and can broker login through external identity providers. Applications register as clients and receive only the roles and claims they require.

• Single sign-on for multiple web applications and APIs.
• Realm and client roles, protocol mappers, scopes and application-specific claims.
• Configurable authentication flows and MFA for logins that actually pass through Keycloak.
• Identity brokering to supported OIDC, SAML and other identity providers.
• LDAP user federation with import choices, edit modes, synchronisation and mappers.
• Access-token, refresh-token and session lifetimes as part of security and deprovisioning.

This makes Keycloak a strong fit for Nextcloud, GitLab, OpenProject, internal portals and custom applications where the deployed version provides a documented OIDC or SAML integration. It does not replace Linux host enrolment, SSSD, HBAC or central sudo policy.

FreeIPA and Keycloak compared directly

The table describes each product’s core purpose. Extensions can enable additional integrations, but they do not automatically replace the other system’s native operating model.

When is FreeIPA the right choice?

Consider an organisation operating dozens or hundreds of Linux systems. Administrators need consistent accounts, SSH authentication, centrally maintained groups, constrained sudo permissions and rules that determine who may access production, test or identity hosts. New systems should be enrolled reproducibly with Ansible, and access should be removed reliably during offboarding.

FreeIPA is the appropriate core service here. Linux hosts consume identity and policy through SSSD; HBAC combines users or groups with host groups and services; sudo rules are modelled separately. Kerberos, DNS discovery and time synchronisation form the technical trust foundation. Automation can repeatedly apply the desired state for hosts and policy.

FreeIPA alone is sufficient when central web applications do not need OIDC or SAML. Adding a Keycloak cluster only for SSH, sudo or Linux login creates new database, proxy, certificate, monitoring and recovery work without improving those host functions.

When is Keycloak the right choice?

A different organisation runs several web applications and custom APIs. Users should authenticate once, use MFA and access applications through deliberately mapped roles. External partners should be able to use an existing identity provider while internal applications consume OIDC or SAML.

Keycloak is the suitable layer for this job. It normalises login paths, issues tokens, manages sessions and translates groups or attributes into client roles and claims. Users can live in Keycloak or come from a supported LDAP source. The right model depends on the source of truth, lifecycle, write permissions and availability requirements.

An additional FreeIPA deployment is unnecessary when there is no Linux domain, no central host policy and no need for Kerberos or SSSD. Keycloak can federate an existing LDAP directory; that does not imply the directory must be replaced by FreeIPA.

When does FreeIPA plus Keycloak make sense?

The combination is useful when an organisation operates both Linux hosts and web applications and wants them to share a controlled identity source. FreeIPA remains the source of truth for Linux identities, groups, hosts, Kerberos, HBAC and sudo. Keycloak provides web SSO, protocol translation, MFA for Keycloak-mediated logins, and application-specific roles and claims.

Text alternative for the architecture diagram

FreeIPA is the central source for Linux users, groups, hosts and host-level access rules. Linux systems retrieve this information through SSSD and Kerberos. Keycloak connects to the required user and group data through LDAP user federation. Web applications trust Keycloak through OIDC or SAML. This does not turn FreeIPA into an OIDC provider, and it does not make Keycloak manage HBAC or sudo rules. Operating-system and application authorisation remain separate decisions.

Federation: the important technical decisions

Imported users or runtime lookup

Keycloak LDAP federation can import users or, depending on configuration and feature boundaries, rely more heavily on the external source at runtime. Imported users receive a local Keycloak record while password validation may still happen against LDAP. The selected edit mode determines whether attributes are read-only, written back to LDAP or managed locally. This must be decided for each lifecycle and attribute; “federated” does not mean “fully bidirectional synchronisation”.

Groups, roles and claims

FreeIPA groups do not automatically become Keycloak roles. LDAP mappers can bring groups into Keycloak, after which realm or client roles and claims need deliberate mapping. Tokens should not contain every directory group. Client-specific scopes reduce data exposure, token size and accidental authorisation.

Passwords, Kerberos and MFA

With LDAP federation, Keycloak can validate credentials against FreeIPA. Kerberos can be added as an authentication path, but it requires correct DNS, time, SPNs, keytabs and browser/proxy behaviour. A crucial boundary remains: MFA in Keycloak does not automatically protect Linux SSH logins. SSH follows its SSSD, PAM, Kerberos and SSH configuration, so MFA must be designed and tested separately there.

Deactivation, tokens and sessions

Disabling an account in FreeIPA does not necessarily terminate already issued access tokens, refresh tokens or application sessions immediately. Synchronisation intervals, caches, token lifetimes, session revocation and application sessions determine when access actually ends. Offboarding must therefore be tested end to end rather than treated as a directory-only change.

Failure behaviour

If FreeIPA is unavailable, SSSD caches may keep known Linux identities usable for a limited period depending on configuration, while new or uncached information is not reliably available. Keycloak login against an unavailable LDAP provider may fail when credential validation or user lookup requires that provider. Already issued web tokens remain a separate state governed by expiry and validation.

If Keycloak is unavailable, new web logins and token refresh are affected. Existing application sessions or tokens may continue depending on lifetime and validation design. Linux login through FreeIPA is not automatically affected. This separation is valuable, but it must be explicit in monitoring and incident runbooks.

Documented, possible, tested or recommended?

• Officially documented: FreeIPA provides directory, Kerberos, host, HBAC, sudo, DNS and PKI functions; Keycloak documents OIDC, OAuth 2.0, SAML, identity brokering, LDAP user federation, Kerberos and authentication flows.
• Technically possible integration: Keycloak can use its LDAP provider with the directory behind FreeIPA and map the required attributes and groups.
• Practically documented by ForgeOne: the existing lab article “Connecting Keycloak to FreeIPA and Red Hat IdM” demonstrates LDAP federation, LDAPS, synchronisation and user lookup. This comparison does not claim a new lab test.
• Architecture recommendation: keeping FreeIPA as the Linux identity source and Keycloak as the web SSO layer reduces duplicate administration. This is a recommendation, not a mandatory product rule; existing directories and governance may justify a different design.

Common mistakes when choosing FreeIPA and Keycloak

• Treating Keycloak as Linux host management. Recommendation: keep enrolment, SSSD, HBAC and sudo in FreeIPA or an equivalent Linux IdM layer.
• Treating FreeIPA as a complete modern web SSO provider. Recommendation: use an identity provider designed for OIDC, OAuth 2.0 and SAML.
• Maintaining users independently in both systems. Recommendation: define one source of truth and clear ownership for attributes, credentials and deprovisioning.
• Equating LDAP groups with Keycloak roles. Recommendation: model mappers, scopes and client roles according to least privilege.
• Assuming MFA applies across protocols. Recommendation: test web SSO, SSH, Kerberos and local recovery paths separately.
• Confusing federation with full bidirectional synchronisation. Recommendation: document import, edit mode, sync direction and conflict behaviour.
• Planning high availability for only one component. Recommendation: include FreeIPA replicas, Keycloak instances, database, DNS, reverse proxy and network dependencies.
• Reducing backup and disaster recovery to VM snapshots. Recommendation: use application-consistent backups and tested recovery for both systems.
• Underestimating combined complexity. Recommendation: combine only when shared identity delivers a clear operational or governance benefit.

Operations, security and high availability

Operating FreeIPA

FreeIPA depends on reliable DNS, consistent hostnames and time synchronisation because Kerberos is sensitive to name and clock errors. Replicas improve availability and maintenance options, but they are not a backup: faulty deletions or configuration can replicate. CA roles, certificate lifecycle, replication topology and DNS discovery belong in monitoring and runbooks.

SSSD caching can cushion short outages for known users and rules, but it is not a blanket offline guarantee. Cache lifetime, cached credentials, HBAC evaluation and the specific service determine behaviour. Recovery procedures must consider versions, roles and replication state and should be rehearsed in isolation.

Operating Keycloak

Keycloak needs a supported, highly available database, TLS, correctly configured hostnames and a reverse proxy that controls forwarded headers. High availability requires multiple Keycloak instances and the documented clustering/cache model. Realm configuration, clients, mappers, authentication flows and signing keys all belong in backup, export and recovery planning.

Token and session lifetimes influence security, availability and offboarding. Lifetimes that are too long delay revocation; lifetimes that are too short increase dependency on Keycloak. Administration endpoints, management ports, database access and proxy boundaries need separate protection.

Operating the combination

The combination adds a federation dependency. New web logins may depend on both Keycloak and FreeIPA, while existing tokens have a separate lifecycle. New Linux logins depend on FreeIPA, network and cache rather than Keycloak. Group changes must pass through federation, mappers and token renewal before applications observe them. That complete chain belongs in functional tests and alerting.

FreeIPA, Keycloak or both?

• Central Linux server management with SSH, HBAC and sudo: FreeIPA.
• Web SSO for multiple applications and APIs: Keycloak.
• Linux hosts and web SSO with a shared identity source: evaluate FreeIPA plus Keycloak.
• Existing LDAP and web SSO only: connect Keycloak to the existing LDAP before planning an additional FreeIPA domain.
• Only a few local applications and no central IAM need: question whether additional identity infrastructure is justified.

The combination is not automatically the best choice. It is justified when shared identity, consistent offboarding and governance outweigh the added work for federation, database, proxy, monitoring, backup and recovery.

Digital sovereignty requires operational capability

FreeIPA and Keycloak are open source, can be self-hosted and use open standards. This supports control over identity and avoids unnecessary dependence on proprietary cloud services. Self-hosting also creates direct responsibility for hardening, updates, keys, certificates, backups, recovery testing, monitoring and incident response.

Digital sovereignty therefore does not come from the licence alone. It comes from documented ownership, reproducible automation, tested recovery paths and the ability to update or replace components under control. An open architecture remains sovereign only if the organisation can operate it securely.

ForgeOne perspective

ForgeOne approaches identity architecture together with Enterprise Linux, SSSD, Kerberos, LDAP, Keycloak, Ansible and platform integration. A robust decision considers the source of truth, protocols, authorisation boundaries, lifecycle, failure behaviour and operational ownership. The existing FreeIPA and Red Hat IdM content covers the Linux side, while the Keycloak page explains web SSO and federation.

For implementation detail, ForgeOne documents connecting Keycloak to FreeIPA and Red Hat IdM and the enterprise architecture with HBAC, sudo and Keycloak. The broader context is available under Security & Identity, Linux & Infrastructure, Ansible and digital sovereignty.

Conclusion

FreeIPA and Keycloak answer different questions. FreeIPA organises Linux identities, hosts and host-level policy. Keycloak connects applications through modern protocols, sessions and claims. Teams with only one of those problems should not automatically operate both platforms. Teams with both can connect them through deliberately bounded federation.

A durable architecture separates the identity source, authentication protocol and authorisation decision. It also documents how deactivation, failures, tokens, caches, backups and recovery actually behave. Only then do two capable open-source products become a manageable identity system.