[keycloak-dev] Groups on SSSD Federation provider

Bill Burke bburke at redhat.com
Wed Dec 7 15:43:15 EST 2016



On 12/7/16 11:05 AM, Bruno Oliveira wrote:
> Hi Bill,
>
> On 2016-12-07, Bill Burke wrote:
>> I think I agree that you shouldn't allow writes for a user backed by
>> SSSD as we have no way of synchronizing changes back, so I think you
>> should redo the SSSD provider so that it doesn't import a local copy of
>> a user and creates a read-only implementation of UserModel.  See the
>> User Storage SPI docs and examples. Specifically:
>>
>> https://github.com/keycloak/keycloak/tree/master/examples/providers/user-storage-simple/src/main/java/org/keycloak/examples/userstorage/readonly
>>
>> This is a barebones example, but hopefully you can extract the necessary
>> knowledge.  Writeup is in master docs:
>>
>> https://keycloak.gitbooks.io/server-developer-guide/content/v/master/topics/user-storage.html
> Thanks for the references, but that's not really the problem today. Every user
> attribute coming from the SSSD federation provider is already read-only.
I don't understand why the problem isn't solvable.

> The same is not true for groups and roles (and I understand why).
> Groups imported from SSSD, still can be changed, but like I mentioned,
> we cannot sync it back. And that's the real issue.
You can fashion your UserModel implementation however you want. Again, 
you don't have to import the user and can sync things when the user is 
loaded from SSSD.  We cache it, then whenever the cache expires, reload 
from SSSD and resync groups.

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.

Bill



More information about the keycloak-dev mailing list