> For the complete documentation index, see [llms.txt](https://www.pranaypourkar.co.in/the-programmers-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.pranaypourkar.co.in/the-programmers-guide/identity-and-access-management-iam/keycloak/user-federation/settings.md).
# Settings
## About
The **User Federation Settings** page in Keycloak allows administrators to **configure how Keycloak connects to an external identity source**, such as LDAP or Active Directory. These settings determine how users are queried, authenticated, synchronized, and represented within Keycloak.
Each federation provider added to a realm has its own set of configuration options grouped by purpose - **connection settings, synchronization settings, edit mode, mappers, and advanced options**.
## Providers
In Keycloak, **Federation Providers** are external identity systems that Keycloak can connect to in order to **authenticate users and fetch user data**. This allows Keycloak to delegate user storage and validation to systems like **LDAP**, **Active Directory**, or **Kerberos**, instead of managing users solely within its internal database.
### Available Providers in Keycloak
#### 1. **LDAP Provider**
The **LDAP provider** is the most commonly used User Federation provider. It allows Keycloak to connect to any LDAPv3-compatible directory, including:
* OpenLDAP
* 389 Directory Server
* Microsoft Active Directory (in LDAP-compatible mode)
* Apache Directory Server
**Key Capabilities:**
* Read users from LDAP
* Sync user attributes (name, email, department, etc.)
* Authenticate against LDAP credentials
* Map LDAP groups to Keycloak groups
* Optional write-back to LDAP (if enabled)
**Use Cases:**
* Internal SSO for enterprise apps
* Reusing corporate LDAP as source of truth
* Hybrid identity setups (e.g., Keycloak + LDAP + OIDC)
#### 2. **Kerberos Provider**
The **Kerberos provider** integrates Keycloak with a Kerberos-based authentication infrastructure, commonly used in environments like:
* Microsoft Active Directory (Kerberos protocol layer)
* MIT Kerberos
* Heimdal Kerberos
**Key Capabilities:**
* Support for **SPNEGO (Smart SSO) / GSSAPI** — allows **browser-based SSO** using Windows credentials
* Authenticate users using their **Kerberos tickets** without needing to type credentials manually
* Works well in domain-joined enterprise networks
**Use Cases:**
* Seamless SSO in **Windows-based environments** (e.g., auto-login with Active Directory credentials)
* High-security enterprise environments where **Kerberos is mandated**
* Legacy systems using Kerberos tickets for access control
**Notes:**
* Requires domain-joined machines and correct DNS setup.
* Keycloak must have a valid service account with Kerberos credentials.
* Not used for user storage — only for **authentication**.
* Often used alongside LDAP for full user resolution.
### General Notes on Federation Providers
* **Ordering Matters**: If multiple providers are configured, Keycloak queries them in the order they appear.
* **Search Behavior**: During login or sync, Keycloak will check each provider for the username match.
* **Provider Visibility**: You can enable or disable a provider without deleting it.
* **Provider Type & SPI**: All providers implement Keycloak’s **User Storage SPI**.
### Typical Architecture with Providers
A realm may include:
* **LDAP provider** → To source user attributes and credentials
* **Kerberos provider** → To authenticate users silently (via tickets)
* **Local users** → For service accounts, admins, or fallback login
Each user is associated with a specific storage provider internally using a **federation link**.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://www.pranaypourkar.co.in/the-programmers-guide/identity-and-access-management-iam/keycloak/user-federation/settings.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.