[keycloak-dev] advanced claim support

[Bill Burke]

On 2/17/2015 9:54 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at 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