[keycloak-dev] Groups on SSSD Federation provider
Bruno Oliveira
bruno at abstractj.org
Wed Dec 7 20:01:54 EST 2016
On Wed, Dec 7, 2016 at 6:43 PM Bill Burke <bburke at redhat.com> wrote:
>
>
> 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.
>
Thanks Bill, groups are reload and re-synced during user's login for SSSD
provider.
>
> 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.
I'm just wondering if, to prevent this, groups should be removed from SSSD
federation provider
codebase for now.
> Bill
>
>
More information about the keycloak-dev
mailing list