Document toolboxDocument toolbox

(sv) Use shared LDAP groups to limit access

Translation needed

The content of this page was copied from another page tree and needs to be translated or updated.

When you finish translation, make sure to

  • Replace the label NEEDS-TRANSLATING with TRANSLATED

  • Remove this macro from the page



This usecase can be modified and applied to various similar scenarios as it covers many usefull techniques.

Usecase assumtions:

  1. We are using a shared LDAP server that is organized in this way:

    1. There are groups representing a customers

    2. Each group contains users

  2. We would like to allow registreation of user in a specific customer database, only if they have a specific role/group

  3. The security is further controlled on application level, so the registratin controll is an aditional step / measure



What we ant to do:

users that login via LDAP, come with specific groups. 

We would like to "push" these groups from LDAP, then our LDAP realm, finally to customer realm. 

We want to make use of these groupos - to controll HDC user rights but also to controll login flow and allowance. 

Step 1: LDAP Group mapper

Make sure there is a group mapper setup for LDAP. This will ensure that groups delivered via LDAP login are passes on to further login steps.

Users in LDAP realm should have a federation link:

Also Groups fetched from LDAP should be visible:



Client connection between LDAP realm and customer realm also includes group mapper:

Step 2: Add Group to Role mapper in main realm

Now moving to a customer realm, we need to add mappers for each role that we want to use.

Create a new mapper, select Claim to Role

Enter Claim as: userLdapGroups

By using these mappers, we will be able to access any groups that are fetched from LDAP. Each group must be mapped here individually to KC Roles.



Step 3: Custom authentication flow

We can create a login flow derived from Frist broker login - as we want to controll if a user that has a specific role can register in the system.

This included linking accounts and adding a new account. The condition to check for roles will not work on early stage of this process (why? The user is already authenticated...)

SO in this example we add a verification as the final step - we will denuy login for all users that do not have a specific role. 

In this case we require users to have "fm-services" role, but remember that this name is only based on earlier mapping done in stpe 2. 



Step 4: Assign authetication flow to specific provider

This should not be used as an only security measure. Proper rights assignment is required as well.

Select a First login flow to our custom login flow that requires specific group/role to complete.Â