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...
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