----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, February 17, 2015 3:30:20 PM
Subject: Re: [keycloak-dev] advanced claim support
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.
Themes was always going to be the place to support internationalization. It's been
designed with that in mind. We can improve on templates around this though. Currently a
user has to override the whole template, but we could introduce the concept of widgets.
This means that instead of overriding the whole registration page for an address the user
can create an address widget template. However, that's probably something we can look
at later. For now we just need to make the claims (including the complex claims such as
address) available to the template.
What about the admin console though? We need some way of displaying and editing complex
attributes there.
Some remaining questions:
* What's the purpose of the .css type on 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.
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(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
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com