[keycloak-dev] Groups on SSSD Federation provider
Marek Posolda
mposolda at redhat.com
Thu Dec 8 07:30:51 EST 2016
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.
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
More information about the keycloak-dev
mailing list