Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

Image RemovedImage RemovedImage AddedImage Added

Users in LDAP realm should have a federation link:

Image RemovedImage Added

Also Groups fetched from LDAP should be visible:

Image RemovedImage Added

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

Image RemovedImage Added

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

Image RemovedImage Added

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.

Image RemovedImage Added

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. 

Image RemovedImage Added

Image Removed


Image Added

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. 

Image RemovedImage Added