[keycloak-user] "Mapper-spanning" LDAP federation and mapping "Composite Roles"

Marek Posolda mposolda at redhat.com
Tue Jun 19 11:20:06 EDT 2018


Hi,

I was wondering when/if someone asks for this flexibility ;) Until now, 
there are not so much people asking for it AFAIK. It won't be bad to 
have this, but I am concerned about complexity. Few things:

- The Groups in Keycloak are represented as tree where every group has 
single parent and no recursion is allowed. In LDAP recursion is possible 
(EG. having "group1" has parent "group2", which has parent "group3", 
which has again parent "group1" ). This limitation applies just to 
Keycloak groups. Keycloak roles are fine.

- If you specify "LOAD_GROUPS_BY_MEMBER_ATTRIBUTE_RECURSIVELY" as a 
value of "User Roles Retrieve strategy", then Keycloak will be able to 
query MSAD recursively. This is using MSAD LDAP_MATCHING_RULE_IN_CHAIN
functionality. So that Keycloak users will be assigned to roles+groups 
from LDAP, which are assigned recursively to them in LDAP. The 
limitation is, that in Keycloak admin console, the relationship between 
Roles, Composite Roles and Groups will not match the relationships from 
LDAP. However the final roles in the token for users should be correct 
and all the transitively assigned LDAP roles should be there. Could this 
help?

Marek

On 18/06/18 17:17, Marco Hünseler wrote:
> Hello there,
>
> I am trying to to import a rather large and complex AD structure into
> Keycloak and I am facing some rather substantial problems with that.
>
> First of all, I have some user groups whose members span over multiple
> subtrees.
>
> Example:
> Group OU 1
> |- Group1
> |- Group1.1
> Group OU 2
> |- Group2
> |- Group2.2
> Where Group1.1 is a member of Group1, Group2.2 is a member of Group2 and
> Group2 is a member of Group1. In reality it is a little bit more complex of
> course and makes much more sense ;-)
>
> Unfortunately, this doesn't seem to work as every group mapper only sees
> its own groups, which leads to (1) that the resulting group-order does not
> remotely match the one that's in AD and worse (2) when telling a group
> mapper to watch out for groups that do not exist in upstream anymore, it
> cleans up everything else.
>
> Second, there are (fortunately seperate) OUs containing groups that
> represent a set of rights granted to the user. Obviously, I want to map
> them as roles. What I cannot archieve is to map these roles, once I import
> them, to the groups they point to. Loading the roles recursively would
> probably possible as well, but I would like to stick to the AD structure as
> close as possible (I'm planning to connect Keycloak to different data
> sources as well and it would be pretty awesome to have some reporting
> against the keycloak db at a later stage).
>
> Third, there are quite a lot of groups with multiple "member"s in AD. When
> listing them, most of them have something in common: They are logically
> used to pool similar roles, so no one needs to manage them one by one.
> Which leads me to think that it would be quite accurate to map them as
> "composite roles". Unfortunately, this does not seem to be supported by the
> role mappers at all and if it was, it would probably also not work over
> mapper boundaries.
>
> TLDR; Keycloak is able to map groups and roles from AD but is completely
> missing functionality to do this cooperatively between mappers. I would
> love to know whether anyone can think of another
> as-good-as-possible-structure-preserving way of mapping this directory
> beast inside Keycloak. Also, I would love to hear about your thoughts
> regarding implementing some "cross-mapper" functionality for the LDAP
> connector and how far it can or should go to get this upstreamed later
> eventually so we can proceed with this on -dev :-)
>
> Thanks for reading!
> Marco
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user




More information about the keycloak-user mailing list