[keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 16 January, 2015 3: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 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)

Should it not be ProfileAttributeType and ProfileAttributeValue?

> 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"?

What's the .css type for?

For internationalization it's best that there's a central place to provide translations rather than it being scattered all over the place. Everything that is displayed to end-users should support two types of values. A name or a key. Does that doesn't need internationalization can just specify the name directly, but to use internationalization a key is entered instead (for example ${myAppName}). The key would then be resolved from the message bundle corresponding to the required language.

> 
> 
> 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
>