[keycloak-dev] advanced claim support

Stian Thorgersen stian at redhat.com
Tue Feb 17 10:40:32 EST 2015



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

I guess we can add validation once you've finished this. We do need to add support for proper validation though (including custom validation), there's quite a lot of people that's asked for it.

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

Are we not creating a OOTB security solution for the average developer rather than for security experts?

I agree claim is more a protocol/token term. IMO we should call it custom user profile and attributes. Of course when it comes to mapping user profiles to tokens it should be mapping attributes to claims.

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


More information about the keycloak-dev mailing list