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