On 2016-12-08, Marek Posolda wrote:
On 08/12/16 13:22, Bruno Oliveira wrote:
> On 2016-12-08, 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.
> >
> > 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?
> +1 Let's do this
Btv. is SSSD supporting just groups or also roles? For LDAP there is some
solution needed for roles too. RoleModel doesn't have "attributes" on it
ATM, but my vote is to add it.
Today only groups. But I would rather to stick with what Bill suggested,
if that's an option.
Marek
>
> > Note: I think we need the "storageID" element in the attribute name
too as
> > single Keycloak group "group1" can be used in group mappings of users
from
> > more userStorage providers.
> >
> > Marek
> >
> > On 08/12/16 02:01, Bruno Oliveira wrote:
> > > > If you're talking about the actual groups changing (their names
or
> > > > > whatever), that's a similar problem we have with our regular
LDAP adapter.
> > > > >
> > > That's exactly what I meant. It's a problem that from my
undestanding we
> > > don't have a
> > > solution now. At the same time, I'm afraid that people start to
change
> > > groups' name
> > > and create several mismatches between KC database and IPA. For example:
> > >
> > > group1 coming from IPA, is edited to group2 on Keycloak. On the next
login,
> > > SSSD federation
> > > identifies that group1 does not exist and try to synchronize it again.
Now
> > > we have 2 groups.
> >
> --
>
> abstractj
> PGP: 0x84DC9914
--
abstractj
PGP: 0x84DC9914