From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>, "Pedro Igor Silva"
<psilva(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Friday, January 16, 2015 12:33:38 PM
Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Pedro Igor Silva" <psilva(a)redhat.com>
>> To: "Bill Burke" <bburke(a)redhat.com>
>> Cc: keycloak-dev(a)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(a)redhat.com>
>>> To: keycloak-dev(a)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(a)redhat.com>
>>>>> To: "keycloak dev" <keycloak-dev(a)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.
IMO, you can use Claims for both cases. Claims are also used to refer to SAML attributes
and vice-verca. Claims are also a very know term in security area.
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