Re: [keycloak-dev] advanced claim support

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Tuesday, February 17, 2015 4:08:47 PM Subject: Re: [keycloak-dev] advanced claim support On 2/17/2015 9:54 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: keycloak-dev(a)lists.jboss.org >> Sent: Tuesday, February 17, 2015 3:30:20 PM >> Subject: Re: [keycloak-dev] advanced claim support >> >> Claims is turning out to be a bit more complicated. There are a lot of >> standard claims that are not a simple mapping between a user attribute >> and the protocol's claim. A perfect example is OIDC's "address" which >> is actually a JSON object, not a simple string value. >> >> As far as layout and internationlization goes, IMO, this should all be >> done within themes. Layouts should be done by extending a theme and >> specifying the attributes you want to manage (within registration and >> user console pages). All the admin console should offer is editing >> theme property pages. Why should it be done this way? >> >> Again, a great example is 'address'. Displaying an address is tricky >> because layout information is required. You can't just generically >> generate a registration, admin console, or user profile page based on >> defined claim types. If you did this you'd get something like this: >> >> Country: >> Street: >> Mobile Phone: >> Postal Code: >> State or Province: >> >> So, I think themes should be extended to support internationalization. >> Users should be required to extend themes to add the claim layouts they >> want. Most will want to do this anyways. Otherwise we'll be >> reinventing HTML inside of a data model. > > Themes was always going to be the place to support internationalization. > It's been designed with that in mind. We can improve on templates around > this though. Currently a user has to override the whole template, but we > could introduce the concept of widgets. This means that instead of > overriding the whole registration page for an address the user can create > an address widget template. However, that's probably something we can look > at later. For now we just need to make the claims (including the complex > claims such as address) available to the template. > > What about the admin console though? We need some way of displaying and > editing complex attributes there. > So far my thought is that there will be a flag on the custom claim: "boolean rendered". If true, then the admin console will generically render the HTML into input the claim. For complex types, the admin console theme will be extended. I might take the same approach for registration and user profile page. > Some remaining questions: > > * What's the purpose of the .css type on UserProfileType? Not applicable anymore. It will not exist. :) > * What about validation? Only validation I will do is make sure that there is no scripting attacks going on.

> * Am I the only one that find the term 'claim' a bit to specialist? I > prefer custom user profiles and user profile attributes, to claims and > claim types. > Pedro seems to think that claim is a well understood term in the security community. My only concern is that claim is more of a protocol term that a user attribute term.

-- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com