[keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint

[Bill Burke]

On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Pedro Igor Silva" <psilva at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, 16 January, 2015 2:30:05 PM
>> Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, January 15, 2015 5:07:22 PM
>>> Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
>>>
>>>
>>>
>>> On 1/15/2015 12:40 PM, Pedro Igor Silva wrote:
>>>> ----- Original Message -----
>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>> Sent: Thursday, January 15, 2015 2:46:11 PM
>>>>> Subject: KEYCLOAK-884 - UserInfo Endpoint
>>>>>
>>>>> Bill,
>>>>>
>>>>>       Is the work you are doing for claims considering the respective
>>>>>       sections
>>>>>       in OpenID Connect specification ? To be more specific,
>>>>>       http://openid.net/specs/openid-connect-core-1_0.html#Claims.
>>>>>
>>>>>       Depending on what you are doing, I think I would need to wait you
>>>>>       finish
>>>>>       in order to full support what is expected from the UserInfo
>>>>>       endpoint.
>>>>>       Meanwhile, I'm already doing everything that is necessary to get
>>>>>       the
>>>>>       endpoint up and running with a basic interoperability based on the
>>>>>       default scope values used to request claims (profile, email,
>>>>>       address,
>>>>>       phone).
>>>>>
>>>>>       Btw, are you planning to configure any type of configuration in
>>>>>       order
>>>>>       to
>>>>>       setup the privacy of certain claims ?
>>>>
>>>> Forget about it. Just noticed you already have support for that.
>>>>
>>>
>>> Nothing beyond a few claims though.  Can't enter in address, phone, etc...
>>
>> I've submitted a PR for this issue. There are some changes to IDToken type
>> that would like to share and discuss.
>>
>> Today, user claims are strongly tied with the IDToken type. They are there as
>> properties of the type itself. From a token perspective, that is how they
>> are represented but from an internal perspective I think we can improve it a
>> little bit by introducing a specific type for user claims.
>>
>> IMO, a best design is to extract those specific claims from IDToken type and
>> get them into a specific UserClaimSet, which also helps to avoid code
>> duplication when claims are needed in different places. Just like we need it
>> in UserInfo.
>>
>> That allow us to better represent/manage user claims internally and keep
>> things more in sync with the specs, without break anything from a token
>> representation or functionality perspective.
>
> I'm not convinced about this. Other than IDToken and UserInfo endpoint I can't see any uses for this.
>
> Also, I reckon this will change a fair bit by introducing custom user profiles. Internally I reckon we'll be using user profiles, not claim-set.
>

My plan was the following:

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