[keycloak-dev] Groups on SSSD Federation provider

Marek Posolda mposolda at redhat.com
Mon Dec 12 03:05:55 EST 2016


On 09/12/16 16:27, Bruno Oliveira wrote:
> On 2016-12-09, Marek Posolda wrote:
>> On 08/12/16 18:55, Bill Burke wrote:
>>> This just sounds like a lot more work than necessary...I mean, how often
>>> are group names going to change?
>>>
>> No idea. Regarding LDAP, nobody complained about the usecase for changing
>> group name. So maybe not do anything for now?
>>
>> Just wanted to point that if we decide to do something, the single
>> federationLink is not sufficient as single Keycloak group can be mapped to
>> users from more different userStorages.
> The original reason behind it was the fact that's possible for admins to
> create inconsistencies between IPA and Keycloak. Just like mentioned
> before.
>
> But it seems like it's not a simple change and like Bill mentioned too
> much. If nobody ever complained, besides QE[1]. I can just update the
> docs mentioned that people should be careful when changing or removing
> groups for SSSD provider.
>
> [1] - https://issues.jboss.org/browse/KEYCLOAK-3904
+1

The changing group memberships for users (joinGroup, leaveGroup) can be 
handled easily by throwing the exception. Just the update of group 
itself is problematic, but LDAP doesn't handle this too ATM...

Marek
>
>> Marek
>>>
>>> On 12/8/16 11:14 AM, Marek Posolda wrote:
>>>> The issue is, that single group can have more links to userStorage,
>>>> not just the single one. That's because single group can be mapped
>>>> to users from more different userStorages.
>>>>
>>>> Example:
>>>> - I have 2 ldap userStorages (eg. ldap1, ldap2).
>>>> - I have group "mygroup" in Keycloak.
>>>> - I have user "ldap1-user" and I want him to join the group
>>>> "mygroup" . The group mapping will be saved in LDAP and the LDAP
>>>> user will be member of LDAP group like "cn=mygroup,dc=ldap1,dc=org"
>>>> - I have user "ldap2-user" and I want him to join the group
>>>> "mygroup" . The group mapping will be saved in LDAP and the LDAP
>>>> user will be member of LDAP group like "cn=mygroup,dc=ldap2,dc=org"
>>>>
>>>> Note that I need this same Keycloak group in both my LDAPs. In first
>>>> LDAP, the group is represented by DN "cn=mygroup,dc=ldap1,dc=org",
>>>> but in second LDAP it is represented by path
>>>> "cn=mygroup,dc=ldap2,dc=org" .
>>>>
>>>>
>>>> So the single properties federationLink+federationIdentifier is
>>>> definitely not sufficient. At least it will need to be a map of
>>>> federationLinks. But then you will need to have something additional
>>>> in the admin console UI to display those federationLinks.
>>>> Considering all of this, my vote is to rather stick with attributes.
>>>>
>>>> Marek
>>>>
>>>> On 08/12/16 16:46, Bruno Oliveira wrote:
>>>>>>> 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.
>>>>>
>>>>
>>>>
> --
>
> abstractj
> PGP: 0x84DC9914




More information about the keycloak-dev mailing list