Hey Eric,
Currently there is no validation nor extension in Keycloak itself which could control
these things. I don’t know Keycloak internals well enough to say if there is a way to
configure that via federation or any other mechanism. Given that keycloak keeps copy of
user records I would expect that some attributes are not backed by federated system. In
the end, point of having Keycloak is sometimes to enrich user model.
I wrote a simple extension (FormAction) which can be plugged into registration flow in
order to build blacklist/whitelist policy. You can check it out here:
;.
Feel free to submit issues on GitHub if you find any bug or gap to be filled in.
Cheers,
Lukasz
On 20 Apr 2018, at 19:53, Eric B <ebenzacar(a)gmail.com> wrote:
I just starting working with KeyCloak (3.4.3) and have been looking at the
user attributes and trying to determine how I can leverage some custom
attributes for my different clients. Two things in particular stand out
when I look at the user attributes:
1) there is no mapping/assignment of attributes per client
2) there is no security assignment on the attributes (ex: what can be
self-administered, what is read-only, what is visible to the client, etc)
This becomes an issue when a user logs into the admin panel. Once he is
logged in, he can essentially post a form with any attributes defined and
these will automatically be persisted in the KeyCloak DB. While I'm not
concerned about CSRF, I am concerned about a malicious user trying to
explode by DB by submitting an extraneous number of attributes that KC will
persist.
Additionally, if I want to use a user attribute to specify some read-only
information about a user, if the user knows the attribute name, he can
override it via a form post. So essentially, I have no way to secure the
attributes.
In a similar vein, I am a bit taken aback that all attributes are
associated to the user only and cannot be assigned to a client. I would
like to be able to specify some client-specific attributes, and have KC
automatically filter the attributes available to a client token
accordingly. Is this not feasible?
Are either of these functionalities implementable through some form of
customization, or are they on the roadmap for a future version?
Thanks,
Eric
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user