Subject ID not returned for public SUB when calling UserInfo

By: attila boncser user 12 Nov 2019 at 2:57 a.m. CST

5 Responses
attila boncser gravatar
Expected behaviour: According to OpenID specification, when UserInfo endpoint is called, the response must contain "sub" parameter which is to be validated with the "sub" parameter value returned in ID token on the client. https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse > The sub (subject) Claim MUST always be returned in the UserInfo Response. > > NOTE: Due to the possibility of token substitution attacks (see Section 16.11), the UserInfo Response is not guaranteed to be about the End-User identified by the sub (subject) element of the ID Token. The sub Claim in the UserInfo Response MUST be verified to exactly match the sub Claim in the ID Token; if they do not match, the UserInfo Response values MUST NOT be used. > Actual behaviour: In the case of when * Client is configured to receive "public" subject identifier (Subject Type = public) and * in oxAuth JSON configuration public subject identifier value is configured to certain values (openidSubAttribute = uid, memberof) Subject Identifier "sub" parameter is missing from UserInfo endpoint response. Additionally: If openidSubAttribute = inum or mail, the sub parameter is correctly returned in UserInfo endpoint response. Also, in the case when Access Token is returned as JWT, "sub" parameter is also present in the access token when its value is inum, or mail, and missing when the value is uid, or memberof. It is possible that further attributes might produce "sub" not returning.. Only scope used is openid, flow used is Authorization flow. Tested with oxAuth-RP. Steps to reproduce "sub" being returned: 1. Create a TestClient 2. Configure client for authorization flow, enable scope openid, change Subject Type to public from pairwise 3. Obtain authorization code with openid scope, access token, UserInfo response (authenticate with admin user for example) 4. "sub" parameter should be present in response and should be equal to the inum of the user. Logs: ``` 2019-11-12 09:51:19,793 TRACE [qtp1094834071-16] [org.xdi.oxauth.auth.Authentica tionFilter] (AuthenticationFilter.java:91) - Get request to: 'https://gluudev6ap p.hp.local/oxauth/restv1/userinfo' 2019-11-12 09:51:19,796 DEBUG [qtp1094834071-16] [xdi.oxauth.userinfo.ws.rs.User InfoRestWebServiceImpl] (UserInfoRestWebServiceImpl.java:124) - Attempting to re quest User Info, Access token = eyJraWQiOiIwMWZkODlmNy1hNmNmLTRiMjUtYjU5NC01NGE1 MDE4YTFlODMiLCJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL2dsdXVkZXY 2YXBwLmhwLmxvY2FsIiwiYXVkIjoiQCEyMDhFLjhEODMuRUNEOC5FQUU1ITAwMDEhMTUzMC5FNzY2ITA wMDghQTFCQS41RDgxLjZDQzkuMzNDNiIsInNjb3BlIjpbIm9wZW5pZCJdLCJjbGllbnRfaWQiOiJAITIwOEUuOEQ4My5FQ0Q4LkVBRTUhMDAwMSExNTMwLkU3NjYhMDAwOCFBMUJBLjVEODEuNkNDOS4zM0M2IiwidXNlcm5hbWUiOiJEZWZhdWx0IEFkbWluIFVzZXIiLCJ0b2tlbl90eXBlIjoiYmVhcmVyIiwiZXhwIjoxNTczNTQ5NTY2LCJpYXQiOjE1NzM1NDg2NjYsInN1YiI6IkAhMjA4RS44RDgzLkVDRDguRUFFNSEwMDAxITE1MzAuRTc2NiEwMDAwIUE4RjIuREUxRS5EN0ZCIn0.KV9nJGS1Y6ap6rGopB01KlKKrTbAqbuMhuS1Is1W35D0NyHa9CtrYLniXhWzOL1s1FOuxQJmDaewF_D50yFGd7Hm8_FuNYjBGN9TcGO90xfo9lhBgx1vdJNDBMbCTYG6A0zL0iDvwJuSO2B66oZxSZO9fbDGK5QEx5b5nwYi0TcRtAJcJkvdDraTqGmFCtP5yD-J7St8PMU47rPzM-Ld1zmG6Pu1bVsTmSTeNIdOPv5Eo3bD0E1paqHqO7qfgeUbuj9JuKTAIuaSNSVzp4da-trBXARYOPYRFOmSsyhZRKS3owaRf_LECb1LwqfNMasROGtirAeSkrzyGfsY0-hZ-Q, Is Secure = true 2019-11-12 09:51:19,804 DEBUG [qtp1094834071-16] [org.xdi.oxauth.service.UserService] (UserService.java:88) - Getting user information from LDAP: userId = admin 2019-11-12 09:51:19,813 DEBUG [qtp1094834071-16] [org.xdi.oxauth.service.UserService] (UserService.java:97) - Found 1 entries for user id = admin 2019-11-12 09:51:19,823 TRACE [qtp1094834071-16] [org.xdi.service.cache.RedisClusterProvider] (RedisClusterProvider.java:95) - put - key: client_id_@!208e.8d83.ecd8.eae5!0001!1530.e766!0008!a1ba.5d81.6cc9.33c6, status: OK 2019-11-12 09:51:19,824 TRACE [qtp1094834071-16] [org.xdi.service.cache.RedisClusterProvider] (RedisClusterProvider.java:95) - put - key: client_dn_inum=@!208e.8d83.ecd8.eae5!0001!1530.e766!0008!a1ba.5d81.6cc9.33c6,ou=clients,o=@!208e.8d83.ecd8.eae5!0001!1530.e766,o=gluu, status: OK 2019-11-12 09:51:19,824 DEBUG [qtp1094834071-16] [org.xdi.oxauth.service.ClientService] (ClientService.java:141) - Found 1 entries for client id = @!208E.8D83.ECD8.EAE5!0001!1530.E766!0008!A1BA.5D81.6CC9.33C6 ``` Steps to reproduce "sub" not being returned: 1. Create a TestClient 2. Configure client for authorization flow, enable scope openid, change Subject Type to public from pairwise 3. Change oxAuth JSON configuration openidSubAttribute to uid 4. Obtain authorization code with openid scope, access token, UserInfo response (authenticate with admin user for example) 5. Response should be empty json string. Logs: ``` 2019-11-12 09:24:07,087 TRACE [qtp1094834071-18] [org.xdi.oxauth.auth.Authentica tionFilter] (AuthenticationFilter.java:91) - Get request to: 'https://gluudev6ap p.hp.local/oxauth/restv1/userinfo' 2019-11-12 09:24:07,091 DEBUG [qtp1094834071-18] [xdi.oxauth.userinfo.ws.rs.User InfoRestWebServiceImpl] (UserInfoRestWebServiceImpl.java:124) - Attempting to re quest User Info, Access token = eyJraWQiOiIwMWZkODlmNy1hNmNmLTRiMjUtYjU5NC01NGE1 MDE4YTFlODMiLCJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL2dsdXVkZXY 2YXBwLmhwLmxvY2FsIiwiYXVkIjoiQCEyMDhFLjhEODMuRUNEOC5FQUU1ITAwMDEhMTUzMC5FNzY2ITA wMDghQTFCQS41RDgxLjZDQzkuMzNDNiIsInNjb3BlIjpbIm9wZW5pZCJdLCJjbGllbnRfaWQiOiJAITI wOEUuOEQ4My5FQ0Q4LkVBRTUhMDAwMSExNTMwLkU3NjYhMDAwOCFBMUJBLjVEODEuNkNDOS4zM0M2Iiw idXNlcm5hbWUiOiJEZWZhdWx0IEFkbWluIFVzZXIiLCJ0b2tlbl90eXBlIjoiYmVhcmVyIiwiZXhwIjo xNTczNTQ3OTMyLCJpYXQiOjE1NzM1NDcwMzJ9.hEGs1O83-Aj_2Sq9V-eU0glSacdPXeY46YB-5pjkCZ h9G5Z2YjapEuomRXIjkOHjYbOR7iIUGfovO2jWdz3uOagf-gB8V6dJas4NCnnHNxZ4CpiGCxFLx0-ZaV WrLoQOdQDEm8SWsbCUAOv-BNRFKfMxTHnsMuXL0sg0zS5ryg5mQBrFVrnjzfwXqFU4tQkQMqaecVxhLJ o_uvjMei-KobEgv7vSJ3vnJSZXSal3XTZQJhfRWkWwW0VIPfe_D1Rmxil9bGTjQaeMhSjFTgFGqRgr25 fXBwHP7sBIDM0V7X-BJTObwZ73GQFApLUbVdoaBpF16PJQ5zKgX85qOXTcwA, Is Secure = true 2019-11-12 09:24:07,112 DEBUG [qtp1094834071-18] [org.xdi.oxauth.service.UserSer vice] (UserService.java:88) - Getting user information from LDAP: userId = admin 2019-11-12 09:24:07,127 DEBUG [qtp1094834071-18] [org.xdi.oxauth.service.UserSer vice] (UserService.java:97) - Found 1 entries for user id = admin 2019-11-12 09:24:07,137 TRACE [qtp1094834071-18] [org.xdi.service.cache.RedisClu sterProvider] (RedisClusterProvider.java:95) - put - key: client_id_@!208e.8d83. ecd8.eae5!0001!1530.e766!0008!a1ba.5d81.6cc9.33c6, status: OK 2019-11-12 09:24:07,139 TRACE [qtp1094834071-18] [org.xdi.service.cache.RedisClu sterProvider] (RedisClusterProvider.java:95) - put - key: client_dn_inum=@!208e.8d83.ecd8.eae5!0001!1530.e766!0008!a1ba.5d81.6cc9.33c6,ou=clients,o=@!208e.8d83.ecd8.eae5!0001!1530.e766,o=gluu, status: OK 2019-11-12 09:24:07,141 DEBUG [qtp1094834071-18] [org.xdi.oxauth.service.ClientService] (ClientService.java:141) - Found 1 entries for client id = @!208E.8D83.ECD8.EAE5!0001!1530.E766!0008!A1BA.5D81.6CC9.33C6 ``` In logs no difference can be found.
Rhel 7.5
closed

Answers

By Mohit Mali staff 12 Nov 2019 at 3:12 a.m. CST

Copy
Mohit Mali gravatar
hi attila boncser, Thanks for reaching out gluu support , we are looking at this issue will update you asap. Thanks and Regards Mohit Mali

By Mohit Mali staff 12 Nov 2019 at 4:15 a.m. CST

Copy
Mohit Mali gravatar
Hi Attila boncser, I need to know following things from you a) Did you try multiplye value of openidSubAttribute at one input like openidSubAttribute = uid, memberof ? b) Can you provide me gluu doc link which you are following. Thanks and Regards Mohit Mali

By attila boncser user 12 Nov 2019 at 4:41 a.m. CST

Copy
attila boncser gravatar
Hi, a) No, I only set one attribute to the openidSubAttribute, I just meant that I tested with those attributes one by one. In the test steps I wrote to only set it to one attribute as well. b) I follow gluu docs for gluu version 3.1.5. https://gluu.org/docs/ce/3.1.5/ https://gluu.org/docs/ce/3.1.5/admin-guide/openid-connect/#subject-identifier-types

By Michael Schwartz Account Admin 12 Nov 2019 at 2:56 p.m. CST

Copy
Michael Schwartz gravatar
Ok, if this is verified it should be moved to the oxauth Github as a bug to be fixed in 4.1

By Aliaksandr Samuseu staff 12 Nov 2019 at 5:17 p.m. CST

Copy
Aliaksandr Samuseu gravatar
I was able to confirm it in 4.0, and created an issue at Github: [link](https://github.com/GluuFederation/oxAuth/issues/1200) Thanks for letting us know, Attila, and for the detailed report as well.

Post an answer