[keycloak-dev] Groups on SSSD Federation provider

[Bruno Oliveira]

On 2016-12-09, Marek Posolda wrote:
> On 08/12/16 18:55, Bill Burke wrote:
> >
> > This just sounds like a lot more work than necessary...I mean, how often
> > are group names going to change?
> >
> No idea. Regarding LDAP, nobody complained about the usecase for changing
> group name. So maybe not do anything for now?
>
> Just wanted to point that if we decide to do something, the single
> federationLink is not sufficient as single Keycloak group can be mapped to
> users from more different userStorages.

The original reason behind it was the fact that's possible for admins to
create inconsistencies between IPA and Keycloak. Just like mentioned
before.

But it seems like it's not a simple change and like Bill mentioned too
much. If nobody ever complained, besides QE[1]. I can just update the
docs mentioned that people should be careful when changing or removing
groups for SSSD provider.

[1] - https://issues.jboss.org/browse/KEYCLOAK-3904

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

--

abstractj
PGP: 0x84DC9914