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(a)redhat.com>
To: keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev