Re: [keycloak-dev] Groups on SSSD Federation provider

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. >> > > >