On 20 Apr 2018, at 19:53, Eric B <ebenzacar(a)gmail.com&gt; 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

On 1 May 2018, at 04:51, Eric B <ebenzacar(a)gmail.com&gt; 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(a)code-house.org <mailto:luke@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/at... <https://github.com/apifocal/apifocal-id/tree/master/keycloak/extension/at...;. 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 <mailto:ebenzacar@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 <mailto:keycloak-user@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>

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(a)code-house.org&gt; 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(a)gmail.com&gt; 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(a)code-house.org&gt; 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/at.... >> 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&gt; 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 >> >> > >