0

I tried to enhance my existing WebApi with IdentityServer3. So I installed the IdentityServer3.AccessTokenValidation package and added this piece of code to my Startup Configuration

app.UseIdentityServerBearerTokenAuthentication(new IdentityServerBearerTokenAuthenticationOptions
        {
            Authority = "<myIdentityServerUrl>",
            ValidationMode = ValidationMode.ValidationEndpoint,

            RequiredScopes = new[] { "api1" }
        });

(I did not apply the AuthorizeAttribute filter, so I can see what's going on). The identity server so far is the exact same as in the docs (code here). I tried to debug-call the test service and I saw that this.User (in the controllers method) was null. So I looked into the RequestContext. Now that was weird:

  • RequestContext.Principals is null
  • RequestContext.Request.Headers.Authorization has the correct access_token

As far as I know even if I made a mistake with the scopes or Authority -what I highly doubt- I should still get the claims. The AuthorizeAttribute would probably return an Unauthorized http message but that doesn't matter because I did not add that filter yet.

Domenic
  • 708
  • 1
  • 9
  • 23
  • The Authorize attribute is what triggers the authorization middleware to setup a principal. Why are you omitting it? – John Korsnes Nov 05 '16 at 22:21
  • I'm omitting the attribute so I can properly debug. With the attribute the WebApi returns an 'unauthorized' message without letting me know what exactly doesn't work as expected. When I use the WebApi from the example it works. And when I remove the AuthorizationAttribute in the provided WebApi the Principal looks like expected (contains my claims). So I really don't think the attribute is what triggers the middleware to setup the principal as you said. – Domenic Nov 07 '16 at 07:16
  • https://leastprivilege.com/2016/08/21/why-does-my-authorize-attribute-not-work/ – John Korsnes Nov 07 '16 at 08:02
  • Thanks for the article. Interesting read! I still don't know exactly what it means for me at this stage because the ClaimsPrincipal doesn't hold the wrong type of claim, the property is just set to null. – Domenic Nov 07 '16 at 08:33
  • Did you try this? Put the `JwtSecurityTokenHandler.InboundClaimTypeMap.Clear(); ` at the very top of your `Startup.cs`. The incoming jwt tokens are providing claims with a different set of types than Microsoft wants you to use. – John Korsnes Nov 07 '16 at 09:00
  • Oh, now I get it, sorry! Tried it now, unfortunately still the same result – Domenic Nov 07 '16 at 09:15
  • Doh. Ok, do you get this sample to work at all? https://github.com/IdentityServer/IdentityServer3.Samples/tree/master/source/Clients/SampleAspNetWebApi And what's the diff between your project and that sample? – John Korsnes Nov 07 '16 at 10:14
  • Hey John, thank you so much for your help. I've created a new question to show what seems to be the real problem: http://stackoverflow.com/questions/40462794/identityserver3-xbehave-test – Domenic Nov 07 '16 at 10:23
  • Do you have `SuppressDefaultHostConfiguration` enabled in your web api config? If yes - this is the reason - either remove it or add a HostAuthentication filter to allow the `Bearer` scheme. – leastprivilege Nov 09 '16 at 09:57

0 Answers0