[keycloak-dev] Groups on SSSD Federation provider

[Bruno Oliveira]

On 2016-12-08, Bill Burke wrote:
>
> On 12/8/16 9:22 AM, Bill Burke wrote:
> >
> > On 12/8/16 7:14 AM, Marek Posolda wrote:
> > > Yes, the thing is that we don't have anything like federation of
> > > groups or roles. And not sure if we need that as it will be lots of
> > > overhead and corner cases around this IMO.
> > >
> > I thought about doing that, but you still have the same synchronization
> > issues.
> >
> > Alternatively, LDAP and SSSD could just map groups into UserModel
> > attributes, then the SAML and OIDC mappers could just map those user
> > attributes into role mappings in the token or assertion.
> >
> >
> > > My vote is something like your solution 2. Maybe the group can have
> > > attribute like "userStorage.<storageID>.id", which will contain the
> > > identificator of particular group specific to particular userStorage
> > > provider. In case of LDAP, it will be either LDAP UUID or LDAP DN of
> > > that group. In case of SSSD probably something similar?
> > >
> > 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.

> >
>
> See above still, but I just want to add that we have to stop doing hacks to
> support a specific edge case.  Instead the SPIs need to be improved.

The only reason why I considered doing that, is because I thought that
we didn't want to change the API. But if that's an option, I'm all for
it.

Should we have a Jira to capture what you suggested?


>
> Bill
>

--

abstractj
PGP: 0x84DC9914