[keycloak-dev] advanced claim support

[Marek Posolda]

On 6.2.2015 17:04, Michael Gerber wrote:
>
>> Am 06.02.2015 um 16:32 schrieb Bill Burke <bburke at redhat.com>:
>>
>> 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“?
> The labels and messages are currently stored in a messages.properties file.
> The best way to internationalize it, would be to create multiple property files (messages_de.properties, messages_fr.properties).
> So you should add a „String label“ field to the UserProfileType, to map a label in the properties file.
IMO it will be good if people are able to localize their claims directly 
in admin console without need to edit some properties files.
So maybe UserProfileType can contain mapping of locales to the "name" in 
particular language. Something like:

Map<String, String> localeMappings;

on UserProfileType. This will allow people to configure labels for their 
claims directly in admin console. So they can specify that "phone" label 
should be available in "English" and "telefon" in "Czech" etc. Maybe we 
can later provide some pre-defined labels for well-known claims (like 
phone) in supported languages when we are going later to add 
localization support.

Marek
>
> why do you need a .css type?
>
>>
>> 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
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev