[keycloak-dev] Groups on SSSD Federation provider

[Bill Burke]

This just sounds like a lot more work than necessary...I mean, how often 
are group names going to change?


On 12/8/16 11:14 AM, Marek Posolda wrote:
> The issue is, that single group can have more links to userStorage, 
> not just the single one. That's because single group can be mapped to 
> users from more different userStorages.
>
> Example:
> - I have 2 ldap userStorages (eg. ldap1, ldap2).
> - I have group "mygroup" in Keycloak.
> - I have user "ldap1-user" and I want him to join the group "mygroup" 
> . The group mapping will be saved in LDAP and the LDAP user will be 
> member of LDAP group like "cn=mygroup,dc=ldap1,dc=org"
> - I have user "ldap2-user" and I want him to join the group "mygroup" 
> . The group mapping will be saved in LDAP and the LDAP user will be 
> member of LDAP group like "cn=mygroup,dc=ldap2,dc=org"
>
> Note that I need this same Keycloak group in both my LDAPs. In first 
> LDAP, the group is represented by DN "cn=mygroup,dc=ldap1,dc=org", but 
> in second LDAP it is represented by path "cn=mygroup,dc=ldap2,dc=org" .
>
>
> So the single properties federationLink+federationIdentifier is 
> definitely not sufficient. At least it will need to be a map of 
> federationLinks. But then you will need to have something additional 
> in the admin console UI to display those federationLinks. Considering 
> all of this, my vote is to rather stick with attributes.
>
> Marek
>
> On 08/12/16 16:46, Bruno Oliveira wrote:
>>>> Should groups and roles instead have a federationLink (which points to
>>>> > >the provider) and maybe also a federationIdentifier (which can contain
>>>> > >things like LDAP UUID) as first class properties?  Then, you can search
>>>> > >for roles and groups based on those properties so you can synchronize
>>>> > >them.
>> That would be fantastic.
>>
>
>
>