[keycloak-user] User Attributes security and organization

[luke at code-house.org]

Hey Eric,
FormAction is one of elements which can be plugged into registration flow, where user enters its credentials and might also enter attributes. Default theme from keycloak does not allow to specify any attributes, but these still can be appended with sequence of cURL requests. FormAction I implemented allows to control that.
After user is registered and logged in his actions are subject of other elements in Keycloak which are not extensible at this moment.
From what I see AccountRestService <https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/account/AccountRestService.java#L187> is still possible to exploit in the way you described. There is no way to solve that with existing SPI that I know.

I would suggest reporting that in JIRA. Without presence in backlog it will never get a traction.

Kind regards,
Lukasz

> On 1 May 2018, at 04:51, Eric B <ebenzacar at gmail.com> wrote:
> 
> 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 <mailto: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 <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 <mailto: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 <mailto:keycloak-user at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>
> 
>