[mitreid-connect] MITREid Connect: getting email, profile claims set?

Thu Jan 19 01:52:07 EST 2017

Hi,
Id token does not contain claims except sub, exp, iss, etc.
One can argue that it is just an authentication token. Therefore, querying the user info is mandatory to get the claims.
It should be possible technically by overriding some classes though.
Beware of the size of the tokens in the implicit flow as everything is passing by the browser.

Envoyé de mon téléphone Windows 10

De : Jason Winshell (Bear River)
Envoyé le :jeudi 19 janvier 2017 02:51
À : jricher at mitre.org; aanganes at mitre.org; mjett at mitre.org; github.com at nemonik.com; mitreid-connect at mit.edu
Objet :[mitreid-connect] MITREid Connect: getting email, profile claims set?

Dear MitreID Connect authors,

I'm experimenting with MitreId OpenID Connect v 1.2.6. I'm trying to retrieve the 'openid email profile' claims sets in authorization implicit grant flow. I'm finding that the resulting id_token in the response does not include the email or profile claims, just minimal a "sub" claim + oauth2. I've run the server in TRACE debug mode to verify what's happening. As far as I can tell, the email address for the built-in test user should be returned. The authorization UI asks me to confirm the basic id information, email and profile info, which I did. I'm sure that the server is seeing the email and profile scopes.

Can you tell me what I'm doing wrong:

My web client invokes the authorize endpoint as:

http://jasonw.bearriver.com:8080/uma-server-webapp/authorize?response_type=token%20id_token&client_id=f34eabb6-0dea-4793-89c6-30ad65f1d742&scope=openid%20email%20profile&redirect_uri=http://localhost/callback&state=453563fe-7e2e-4e74-a6ca-266c384bbccc

What follows are snippets from UMA Server logs....

You can see that scope is "openid email profile" is passed in the URL

DEBUG: org.mitre.openid.connect.web.AuthenticationTimeStamper - Redirecting to DefaultSavedRequest Url: http://jasonw.bearriver.com:8080/uma-server-webapp/authorize?response_type=token%20id_token&client_id=f34eabb6-0dea-4793-89c6-30ad65f1d742&scope=openid%20email%20profile&redirect_uri=http://localhost/callback&state=453563fe-7e2e-4e74-a6ca-266c384bbccc

Here you can see that the email address is being processed:

TRACE: org.springframework.web.servlet.view.JstlView - Rendering view with name 'approve' with model {authorizationRequest=org.springframework.security.oauth2.provider.AuthorizationRequest at 187eb553, org.springframework.validation.BindingResult.authorizationRequest=org.springframework.validation.BeanPropertyBindingResult: 0 errors, auth_request=org.springframework.security.oauth2.provider.AuthorizationRequest at 187eb553, client=org.mitre.oauth2.model.ClientDetailsEntity at 70a044c3, redirect_uri=http://localhost/callback, scopes=[SystemScope [id=1, value=openid, description=log in using your identity, icon=user, defaultScope=true, restricted=false, structured=false, structuredParamDescription=null, structuredValue=null], SystemScope [id=2, value=profile, description=basic profile information, icon=list-alt, defaultScope=true, restricted=false, structured=false, structuredParamDescription=null, structuredValue=null], SystemScope [id=3, value=email, description=email address, icon=envelope, defaultScope=true, restricted=false, structured=false, structuredParamDescription=null, structuredValue=null]], claims={openid={sub=01921.FLANRJQW}, profile={name=Demo User, preferred_username=user}, email={email_verified=true, email=user at example.com}}, count=0, contacts=admin at example.com, gras=false, org.springframework.validation.BindingResult.auth_request=org.springframework.validation.BeanPropertyBindingResult: 0 errors, org.springframework.validation.BindingResult.client=org.springframework.validation.BeanPropertyBindingResult: 0 errors} and static attributes {}

TRACE: org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod - Invoking [AuthorizationEndpoint.approveOrDeny] method with arguments [{scope_openid=openid, scope_profile=profile, scope_email=email, remember=none, user_oauth_approval=true, authorize=Authorize}, {authorizationRequest=org.springframework.security.oauth2.provider.AuthorizationRequest at 187eb553}, org.springframework.web.bind.support.SimpleSessionStatus at 4e2834c9, org.springframework.security.authentication.UsernamePasswordAuthenticationToken at 442be9fb: Principal: org.springframework.security.core.userdetails.User at 36ebcb: Username: user; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_USER; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails at 0: RemoteIpAddress: 192.168.0.111; SessionId: 07D41D9C8A0B9BAC78F1BC2CE3CB2714; Granted Authorities: ROLE_USER]

Finally, the id_token in the response to the redirect call back is:  (after confirming access to the information in the UI)

TRACE: org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod - Method [approveOrDeny] returned [org.springframework.web.servlet.view.RedirectView: unnamed; URL [http://localhost/callback#access_token=eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJ1c2VyIiwiYXpwIjoiZjM0ZWFiYjYtMGRlYS00NzkzLTg5YzYtMzBhZDY1ZjFkNzQyIiwiaXNzIjoiaHR0cDpcL1wvamFzb253LmJlYXJyaXZlci5jb206ODA4MFwvdW1hLXNlcnZlci13ZWJhcHBcLyIsImV4cCI6MTQ4NDc5MTUwNiwiaWF0IjoxNDg0Nzg3OTA2LCJqdGkiOiI4ODlkZGIxZS00N2U1LTQ0OTEtODhmZC1jNjdlNjE2ZjM5NWEifQ.qtx4cSY6G8KzEauKBIItGICE3Su47fh7gnFSVy3KfKkGmOC18XKU52Zk5tO1Ld_350WYklBFHp2lkwqDR-J7tykGoubO_Yn7s-2DrTj05jVa9MW6-zEixWtw_ee7cwBt0x7kC8HELgjQgfSX1dPY58lV_SqzhFsg8SAGidYkMZof2xXkk-Xss4yaRjpk2SxUcfMFFX3NWnSB4MpKTApJKEuDFeNo3UgKq26JrrD1l6eqABwuHfMgS_bLSTJjliXuegwvGicQbxw258u8q0_TVBmr7LV1OOtuwWJG2r9-A7T64vJ31lLAJuJLeYj-ugwBBqAY0fRN6n78E3p-oh2YwA&token_type=Bearer&state=453563fe-7e2e-4e74-a6ca-266c384bbccc&expires_in=3599&id_token=eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJhdF9oYXNoIjoiR2lITzdGLWpNTjVCeDR0ZFRRTzUwUSIsInN1YiI6IjAxOTIxLkZMQU5SSlFXIiwiYXVkIjoiZjM0ZWFiYjYtMGRlYS00NzkzLTg5YzYtMzBhZDY1ZjFkNzQyIiwiYXV0aF90aW1lIjoxNDg0Nzg3ODk2LCJraWQiOiJyc2ExIiwiaXNzIjoiaHR0cDpcL1wvamFzb253LmJlYXJyaXZlci5jb206ODA4MFwvdW1hLXNlcnZlci13ZWJhcHBcLyIsImV4cCI6MTQ4NDc4ODUwNiwiaWF0IjoxNDg0Nzg3OTA2LCJqdGkiOiI4MzYxN2ZmYi03MTU5LTQ3YzUtOGM1YS1kYWY0ZWQyYmQwMjMifQ.dYjrDRFroldKe9uNnA0xhi3L6ugvULkAtG7X2kllW5Zscl7165N_ezBRpuDt187WzCo1UOtlj7iL3TWEX0vV7-UEJgbSjMe9HThLD4FR9Y2QPVoUnCLZAzgiJkm_toE62hPXrWmgxn8W58BvxoAU6SVduA-jCXK-b7Gqrh-hy95YhwZFNU0sKY_XWeEfWYbLvEtDULfFpxFbVxsgJ-5kUx7JH-YNqk4hq6bS3_cqJZ4akrkhrAt2We8m1nnJtPm7_XFtFqsXtVuvgR2kUy7iW9bVetpqqbC4NGhvDY9-lILy8wQReXPecP2OQqX-VioAZiaXNNgc56r4SjGFQZMODg]]

The id_token decodes to:

{
  "at_hash": "GiHO7F-jMN5Bx4tdTQO50Q",
  "sub": "01921.FLANRJQW",
  "aud": "f34eabb6-0dea-4793-89c6-30ad65f1d742",
  "auth_time": 1484787896,
  "kid": "rsa1",
  "iss": "http://jasonw.bearriver.com:8080/uma-server-webapp/",
  "exp": 1484788506,
  "iat": 1484787906,
  "jti": "83617ffb-7159-47c5-8c5a-daf4ed2bd023"
}

I'd expect to have seen an email {email, email_verified} and profile {preferred_username, name} for 'Demo User', as created by the default installation.

-- By default, the username column here has to match the username column in the users table, above
INSERT INTO user_info_TEMP (sub, preferred_username, name, email, email_verified) VALUES
  ('90342.ASDFJWFA','admin','Demo Admin','admin at example.com', true),
  ('01921.FLANRJQW','user','Demo User','user at example.com', true);

I'm able to get the info from the userinfo endpoint using the Bearer token. But I want the info in the id_token. That should be possible?

After hours of debugging the server code & Googling I'm throwing in the towel. Put me out of my misery :-( What am I missing?

Thanks
Jason

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20170119/3da0694c/attachment-0001.html