Implement UserInfo Endpoint

[jgrandja]

This issue will deliver OpenID Connect 1.0 UserInfo Endpoint.

Related gh-53

[idosal]

Hey, I'd love to take this when it opens up.

[jgrandja]

Thanks for your interest @idosal.

Please ping me towards end of January as a reminder.
We'll likely start the work on this at that time.
Thanks!

[amit-github-personal]

Hey @jgrandja , let me know when you're going to start working on OPENID Connect. I also want to work when it opens up

[idosal]

@jgrandja Still waiting on this. :)

[jgrandja]

Thanks for the offer @amit-github-personal . Work has already started on OIDC with #53 being merged last month.

As well, @idosal reached out last month and is interested in taking on this feature. Please stay tuned for upcoming features as they open up. It looks like features planned for 0.1.1 have all been assigned.

@idosal I'm planning on focusing on 0.1.1 feature development after I get 0.1.0 out on Feb 11. The UserInfo endpoint is scheduled for 0.1.1, so please go ahead and review the spec to gain an understanding of the requirements. Let me know if you have any questions.

[idosal]

@jgrandja Thanks, I'll get on it.

[idosal]

Hey @jgrandja, after reviewing the spec I started playing around with the code. I have a few questions I'd like to clear up:

1. Where should I get the claims? Is it implemented elsewhere, or is it a part of this task?
2. I'm unclear about this passage: If the UserInfo Response is signed and/or encrypted, then the Claims are returned in a JWT and the content-type MUST be application/jwt. The response MAY be encrypted without also being signed. If both signing and encryption are requested, the response MUST be signed then encrypted, with the result being a Nested JWT, as defined in [JWT]. How should I handle this scenario?

[jgrandja]

@idosal

Where should I get the claims? Is it implemented elsewhere, or is it a part of this task?

It is part of this task. The "source" for the claims will come from the attributes in the Resource Owner's Authentication, specifically Authentication.getPrincipal(). Given that Authentication.getPrincipal() could be different types of Principal objects, this will need to be configurable and the application would need to supply the "Mapper" instance.

For example, let's assume the configuration of a specific Authorization Server deployment authenticates users against an LDAP directory. During the authentication process, it will authenticate the user and upon successful authentication it will set the SecurityContext with the Principal model -> LdapAuthentication.LdapUser (hypothetically). The LdapUser instance would be obtain via currentAuthentication.getPrincipal() (the "source"), and then the attributes within would need to be mapped to the standard claims defined in OidcUserInfo. As mentioned above, we need this "Mapper" to be confgurable because it will be different depending on the Authentication scheme being used and supported by the Authorization Server deployment.

Does this make sense?

FYI, there are a few different ways the client can request claims. For this initial iteration, we will need to support "5.4. Requesting Claims using Scope Values" (defined in OidcScopes).

Regarding your 2nd point, we will not support JWS, JWE or Nested JWS within JWE for the UserInfo response. We'll keep it simple for the initial iteration, which is to return a application/json response.

[Scarange]

any update on this?