[keycloak-user] User Attributes security and organization

[Eric B]

Hi Lukasz,

Thanks for the extension.  I took a quick look at it, and I think it should
be able to help me out.  I wonder if I need to be concerned about keycloak
API accesses that need to be secured as well, since your FormAction is
clearly a UI related thing.  I haven't had a chance to look at the API yet,
however, and/or if there is something I would need to do along that line as
well.

Thanks!

Eric


On Mon, Apr 30, 2018 at 11:00 AM, <luke at code-house.org> wrote:

> 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: https://github.com/apifocal/apifocal-id/tree/
> master/keycloak/extension/attributes.
> 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>