LDAP (Lightweight Directory Access Protocol) is a protocol for directory service providers. Active Directory is a directory service provider. LDAP is the "API", Active Directory the "backend" with the database.
Microsoft reveal Active Directory in 1996, first wide deployment was in 1999 with Windows 2000 server
LDAP was created in 1992, that's why this protocol is mostly used on multi-users systems.
For this examples, we have :
Our directory has a standard structure :
There are 2 entries in Keycloak : User federation and identity provider. Those two approaches are significantly different, by the method and the result. The result is not how users are provided.
By "identity provider", it means an identity server. Authentication process is delegated to the identity provider. Only if the user exists, is correctly authenticated and gives the right permissions the identity provider will return the identity. Check our blogpost about Authorization code.
"The way we store users" could be a good way to explain it. We can replace the user's management delivered by default in Keycloak by another method. It works with LDAP or Keberos by default, there are also some developer interfaces (SPI) if you want to code your own user management.
First of all, we have to get the user structure and properties. With LDAP Admin it is easy :
Then we have enough informations to fill the LDAP configuration in Keycloak.
Our advice is : do not rely on default values provided by "vendor" values. Check the right values using a LDAP explorer software.
Save the configuration, then you can synchronize all users for the first time.
Our users are now in the database, let's take a look :
Users details are filled by the default import. Note the "Verify email" action required.
In the LDAP configuration we do not check "trust email" in "Advanced section"
More attributes are also provided by default mappers :
Those mappers are defined in the "mappers" section :
Credentials are provided directly by the LDAP, so the entry shows this :
GREAT ! The user's synchronization works perfectly as we want. We define a synchronization period :
In LDAP, we can organize users by groups (with a property "memberOf"). This concept of "groups" does not exist in oauth2/openid Connect. There is only role mapping (realm roles or client roles) with users.
Keycloak has its own group implementation. This implementation is only a role mapping shortcut, each member of a group will have the role.
Check the groups structure in the LDAP Admin :
Now, add a new LDAP Mapper, with the type "group-ldap-mapper", then we have to fill a big form like seen previously :
Then, we sync all.
The Keycloak group structure is now the same that is defined in our directory :
Of course, we have correctly filled the users attributes so the users are affected to their groups.
We have an Organizational Unit for roles. It is also the same as groups. In Keycloak, we will define the mapping directly to roles.
Check all attributes names :
Define a new LDAP Mapper, using the mapper type "role-ldap-mapper". Fill all fields with values we got previously :
2 ways exist for roles : realm role (global) or client based roles.
We chose the "backend" client for our use. The mapping will create roles in the client.
Users will have the roles assigned after synchronization :
Keeping the same structure between LDAP and openid connect is great for already running projects. As consultants, we see many companies that rely on their directory structure, the only source of truth.
Keycloak can use the directory in read only mode or with a bi-directionnal synchronization. Do not forget to consider it.