[keycloak-dev] advanced claim support

Stian Thorgersen stian at redhat.com
Tue Feb 17 09:54:33 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 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.

Some remaining questions:

* What's the purpose of the .css type on UserProfileType?
* What about validation?
* 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.

> 
> On 2/17/2015 8:15 AM, Stian Thorgersen wrote:
> > Forgive my lateness in replying to this, I've been busy playing with kids
> > and drinking cask ales ;)
> >
> > With regards to internationalization we should support that by using keys
> > in place of values. We'll provide a default set of keys including
> > translations to some languages. Additional keys (and translations) can be
> > supplied through themes. We should also add a mechanism to do the
> > translations through the admin console.
> >
> > As an example, someone not using internationalization could create a claim:
> >
> > * id: 'first_name'
> > * name: 'First name'
> >
> > While someone using internationalization would create a claim with a key
> > instead:
> >
> > * id: 'first_name'
> > * name: 'user.first_name'
> >
> > We can do a lot in the admin console to make it easier for users to deal
> > with internationalization. For example when internationalization is
> > enabled internationalized fields such as 'name' becomes a button that
> > opens a modal panel that allows selecting an existing key, creating a new
> > key, adding translations, etc.).
> >
> > A few questions with regards to claim support:
> >
> > * What's the purpose of the .css type for UserProfileType?
> > * What about validation?
> > * 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.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, February 6, 2015 4:32:16 PM
> >> Subject: [keycloak-dev] advanced claim support
> >>
> >> Wrote this awhile ago.  I'm starting on this now.  Discuss now, or
> >> forever hold your peace :)
> >>
> >> Current UserModel.attributes will be used for internal bookkeeping only.
> >>     Going to add a new "UserProfileType", "UserProfileValue" (name TBD)
> >> type that contains:
> >>
> >> UserProfileType:
> >> * id
> >> * name
> >> * .css type
> >> * type (bool, int, date, etc.)
> >> * boolean displayOnRegistrationPage
> >>
> >> Question, do I need a .css id to plug in a value too?  How would we
> >> display the german label name for "phone"?
> >>
> >>
> >> UserProfileValue:
> >> * id
> >> * UserClaimType
> >> * String value
> >>
> >>
> >> OIDC clients will have a "Claim mapping" tab.  SAML clients will have an
> >> "Assertion Mapping" tab.  These tabs will be able to map from
> >> UserProfileValues to te appropriate claim/assertion and also be able to
> >> set up whether or not a claim should be added to token/assertion list.
> >>
> >> ClientModel.claimMask will go away.  ClientModel will gain a list of
> >> ClaimMappingModel
> >>
> >> * id
> >> * UserProfileType
> >> * String claimNameMapping
> >>
> >> Might want to eventually add a "ClaimTransformerProvider" pluggin
> >> ability that can be attached to ClaimMappingModel...We might also want a
> >> "TokenTransformerProvider" plugin too that can intercept token/saml doc
> >> creation.  We'll see...
> >>
> >> Bill
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 


More information about the keycloak-dev mailing list