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-...
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/topi...
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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
abstractj
PGP: 0x84DC9914