[keycloak-dev] advanced claim support

[Bill Burke]

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.

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