[keycloak-user] User Attributes security and organization

[Łukasz Dywicki]

Hey Eric,
Issue you refered doesn't exist. Can you check what happened? I would
like to watch it progress too.

Cheers,
Lukasz

2018-05-02 6:01 GMT+02:00 Eric B <ebenzacar at gmail.com>:
> 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 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
>>>
>>>
>>
>>
>