[keycloak-dev] advanced claim support

[Stian Thorgersen]

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
>