Failed authorization for an authenticated user redirects to login page instead of access denied page

[leastprivilege]

A failed role check with the Authorize attribute redirects an authenticated user back to the login page. I haven't checked the internals, but that seems to indicate you are emitting a 401.

My assumption was that in that situation a 403 should be emitted and the cookie middleware will use the AccessDeniedPath instead.

[Tratcher]

See https://github.com/aspnet/Security/blob/dev/src/Microsoft.AspNet.Authentication.Cookies/CookieAuthenticationHandler.cs#L319

[brockallen]

Yes, that API is very easy to read :)

[leastprivilege]

OK - but I am returning a 403 for an authenticated user - and this code path does not seem to get hit..

[Tratcher]

You'd think that 403 would be the appropriate thing to return, but what they eventually settled on is returning a 401 and having the auth middleware that produced the user identity (cookies) change it to a 403 OR redirect to AccessDeniedPath.

[HaoK]

Yep, need to convince @lodejard if you want to change this behavior...

[kevinchalet]

Related ticket: #134

[leastprivilege]

OK - fair enough.

But still it does not work.

I authenticate using cookie MW and hit a Authorize attribute with a role check - role check fails and I get redirected to login page. I have an access denied page set on the cookie MW.

Am I doing something wrong?

[Tratcher]

@HaoK ?

[bojanrajkovic]

So, according to @lodejard, they should already be acting like this: https://twitter.com/loudej/status/601074953836834816

In my tests with 1.0.0-beta5-12413 versions of AuthN/AuthZ packages, this isn't working -- an authenticated, but not authorized, user is still getting a 302 redirect to the login page.

[HaoK]

Looks like the issue is 401->403 not working for automatic authentication, which is always the case for the Authorize(Roles = "Foo"). Things seem to work via an explicit policy where ActiveAuthenticationScheme includes the Cookie... Still investigating

[HaoK]

Yup, confirmed this workaround should work @leastprivilege @bojanrajkovic can you try this and see fixes the issue?

                options.AddPolicy("Cookies", policy => {
                    policy.AddAuthenticationSchemes("Cookies");
                    policy.RequireAuthenticatedUser();
                });

And then an addition [Authorize("Cookies")] in your controllers, all this does is explicitly force the cookie middleware to get authenticate called before authorization happens.

[bojanrajkovic]

@HaoK Confirmed, that works! I added that configuration snippet and added [Authorize("Cookie")] in addition to my existing role-based authorize attribute, and now I get a 403 instead of endless redirects.

[HaoK]

Awesome thanks, just wanted to make sure this is the same root issue, I'll work on the fix shortly...

[HaoK]

e54d088

[bojanrajkovic]

This should be in builds now, right? We don't need that workaround from earlier?