[keycloak-user] User Attributes security and organization

[Eric B]

Thanks Lukasz,

Good point.  I created a ticket here:
https://issues.jboss.org/browse/KEYCLOAK-7271

This is a big security concern for me.  It means that I can't user the
attributes for anything that I would want to ensure don't get changed by a
user.  It also means that an attacker can use the attributes to spam the
DB.  I'll have to see if there is anything I can hack around the system.

Thanks,

Eric

On Tue, May 1, 2018 at 5:19 PM, <luke at code-house.org> wrote:

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