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