Add ability to specify custom ValidateIdentity

[billpratt]

We have a need to call User Info after an access token has been validated. This PR adds the ability to specify the IOAuthBearerAuthenticationProvider and use an override of ValidateIdentity.

[dnfclas]

Hi @billpratt, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution! This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, DNFBOT;

[bschmidt]

:+1:

[leastprivilege]

Hi,

a few comments

• ContextProvider is needed internally. If you replace it, you are hard-wired to tokens on the authZ header
• Wouldn't an extra notification make more sense?

[leastprivilege]

..or maybe even a separate middleware to do claims transformation?

[billpratt]

I wanted to do something similar to how "UseOpenIdConnectAuthentication" handles it with Notifications but I wasnt sure how it would fit it. Are notifications currently being used anywhere or would I have to add that feature?

[leastprivilege]

..and why does it need to be a notifcation. Why not a separate middleware running after token validation?

[billpratt]

I liked notifications because it follows the same pattern to UseOpenIdConnectAuthentication to keep it consistent. I'm not opposed to middleware. If you want middleware, I'll do middleware. Its your party, I'm just attending :)

[leastprivilege]

I am trying to discuss this ;)

The whole middleware idea is about composing functionality. So I was wondering why not put your userinfo call into a claims transformation middleware.

[billpratt]

Understood. I like the middleware idea because its adding to the pipeline. Unlike the scopes required middleware where the code to run is hard coded in the class, would you allow the developer to specify what to run after the token has been validated?

[billpratt]

Should I be working out of "dev" or "master"

[leastprivilege]

In essence this middleware already exists - i might re-publish it with the new namespace etc

https://github.com/IdentityModel/Thinktecture.IdentityModel/tree/master/source/Owin.ClaimsTransformation

The only thing that is missing is, the token validation MW should have an option to preserve the access token as a claim so you can do whatever you want with it during transformation.

https://github.com/IdentityServer/IdentityServer3.AccessTokenValidation/issues/44

[billpratt]

Ah perfect. In order to use it here though you'll have to port it over or add a nuget dependency to IdentityModel? Or should this be added to the pipeline outside of this library?

[billpratt]

So once #44 gets released on nuget, I can use that change along with https://github.com/IdentityModel/Thinktecture.IdentityModel/tree/master/source/Owin.ClaimsTransformation to get what I need. I'll close this pull request.

[CrescentFresh]

This might be supported now (2.2.2), see https://github.com/IdentityServer/IdentityServer3.AccessTokenValidation/pull/52

[leastprivilege]

I still think that for transformation - as separate middleware is the better approach.