Am 06.02.2015 um 16:32 schrieb Bill Burke <bburke(a)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.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev