[keycloak-dev] Groups on SSSD Federation provider
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:
> >> This is a barebones example, but hopefully you can extract the necessary
> >> knowledge. Writeup is in master docs:
> > 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
> 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
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,
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
codebase for now.
More information about the keycloak-dev