[keycloak-dev] Groups on SSSD Federation provider

[Bruno Oliveira]

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.

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.

>
> Really you should also expand it to be able to pull in any arbitrary
> attribute as well as currently its only name and email.
>
> On 12/7/16 7:02 AM, Bruno Oliveira wrote:
> > Good morning,
> >
> > Today I was chatting with Marek, about this issue[1]. It pretty much
> > relates to my previous thread about having read-only groups/roles.
> >
> > In summary, groups are not tightly coupled to Federation providers.
> > So, to prevent read-only users from joining/leaving groups, at
> > joinGroup and leaveGroup methods, thrown an exception,
> >
> > This is pretty much fine. However, the admin still can edit
> > the group and it's not possible to synchronize it back to SSSD —
> > everything is read-only.
> >
> > That said, I was thinking if we really should synchronize user's
> > groups coming from SSSD or not. Because the chances of having a
> > group/role mismatch because someone decided to change its name is
> > high.
> >
> > I can see two alternatives:
> >
> > 1. Never synchronize user's group from SSSD. We cannot synchronize it
> > back and I'm not sure how this information is relevant into our context.
> > For authentication with PAM, we don't need this information.
> >
> > 2. We keep it and permit the admin to change, but internally we preserve
> > the original name synchronized from SSSD. Maybe make the original name,
> > the id.
> >
> > Thoughts?
> >
> > [1] - https://issues.jboss.org/browse/KEYCLOAK-3904
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj
PGP: 0x84DC9914