Auth 2.0 Part II: Revenge of AuthZ

[HaoK]

Sequel to: #1179

Authentication:

Host Wave PRs:

• HttpSys: Prototype Auth 2.0 changes HttpSysServer#325
• IISIntegration: Auth 2.0 + IISListener IISIntegration#338
• AspNetCoreModule: Only register the auth handler based on the environment variable IISIntegration#371
• ServerTests

Cleanup PRs/Issues:

• Options Initializer support: Add Initialize<TOptions> Options#187
• Replace Auth double locking with Initialize for fixup Switch to services.Initialize<TOptions> #1206
• Rationalize AddXyz() behavior: Standardize services.AddXyz() behavior with default config #1191 PR: Add ConfigureAspNetCoreDefaults MetaPackages#118
• Obsolete HttpAbstractions: Obsolete Auth 1.0 HttpAbstractions#806
• Revisit Events/Context Auth 2.0 Cleanup: Revisit cleanup events/context #1181
• Reenable ApiCheck
• Fixup all the samples to use new Identity API again

Issues:

• Need docs/Migration: Write a migration guide for Authentication 1.0 to 2.0 dotnet/AspNetCore.Docs#3054

Authorization: #1193

• 401 vs 403, error/diagonstics: AuthZ 2.0 Improve failure scenarios + [401 vs 403?] #901
• Shared AuthZPolicyEvaluator: Prototype shared AuthorizationPolicyEvaluator #1148
• Add IAuthorizationHandlerProvider: Add IAuthorizationHandlerProvider interface #1176

[ryanelian]

Hello, I've been reading the threads from aspnet/Announcements#232

I have a question, let's say I have an authentication setup like below:

app.UseWhen(context => context.Request.Path.Value.StartsWith("/api", StringComparison.OrdinalIgnoreCase), builder =>
{
    builder.UseCookieAuthentication(new CookieAuthenticationOptions
    {
        AuthenticationScheme = AuthService.CookieAuthenticationScheme,
        AutomaticAuthenticate = true,

        AutomaticChallenge = false,
        LoginPath = null,
        LogoutPath = null,
        AccessDeniedPath = null
    });
});

app.UseWhen(context => context.Request.Path.Value.StartsWith("/api", StringComparison.OrdinalIgnoreCase) == false, builder =>
{
    builder.UseCookieAuthentication(new CookieAuthenticationOptions
    {
        AuthenticationScheme = AuthService.CookieAuthenticationScheme,
        AutomaticAuthenticate = true,

        AutomaticChallenge = true,
        LoginPath = "/auth/login",
        LogoutPath = "/auth/logout",
        AccessDeniedPath = "/home/denied",
    });
});

The goal of above code is to prevent API-type endpoints (that returns JSON) to redirect user to login page when authentication fails. (Instead just return 401 Unauthorized or 403 Forbidden)

How can I do this using the new authentication middleware?

Thank you for advice, in advance.

[Tratcher]

@ryanelian The Policy recommendations in #1062 still work for your scenario.

[ryanelian]

I just read that link. I don't understand.

If I'm not mistaken, I'm supposed to put a policy in my Authorize attributes so it takes effect, like: [Authorize("ApiPolicy")]. But I don't see how that is relevant for branching my authentication middleware. Besides,

• I do not wish to pollute my Authorize attributes with policy just for doing this...

• If you have seen my above example, both middleware uses the same scheme. How am I supposed to do that?

Can you please provide code sample specifically for the above case, please?

[HaoK]

You can't do that anymore, each scheme is now unique, and since they are no longer middleware you can't branch your app to use the same logical scheme for different middleware. You will need to setup two schemes, "Api", "Cookies"

[ryanelian]

I have a mixed feeling about this. I feel that the change unnecessarily complicates the development. The service-based authentication feels like 10 steps backward to me, idk.

There should be a simple way to define the default scheme used for controllers by route / request / context condition...

But okay, let's say I can just explicitly tell the API Controller to use Api scheme, I'll just need to set the CookieName to the same name as the Cookie scheme, is that correct?

[HaoK]

If there was a way to specify services per route/request/context that would just work, but there isn't today...

I'm not sure what you are asking about with the cookie name, but you can keep using the cookies as the DefaultAuthenticateScheme for your non API requests, if your API controller is going to explicitly ask for the API.

[ryanelian]

If there was a way to specify services per route/request/context that would just work, but there isn't today...

There was, it was called Middleware with UseWhen. 😕

I mean, look. I don't mind changing the authentication in my applications into Services but aren't we losing a crucial feature here?

I'm not sure what you are asking about with the cookie name

Let's say in 1.1, I make a cookie authentication scheme called MyAppIdentity.

Apparently ASP.NET will make a cookie for that scheme named .AspNetCore.MyAppIdentity.

Now you're advising me to make 2 separate authentication schemes, 1 = cookie for UI, 1 = cookie for API. Let's say I do that,

• Authentication scheme for UI-type Controller = Cookie
• Authentication scheme for API-type Controllers = Api.

However, the cookie for the schemes will be different, no?

• Cookie name for Cookie scheme = .AspNetCore.Cookie
• Cookie name for Api scheme = .AspNetCore.Api

Thus the question, can I use two different cookie authentication schemes, but targets the same cookie key / store / name?

[HaoK]

I don't think there should be any issues targeting the same cookie name with different schemes, you might have to make sure to configure the TicketFormat for both schemes to be the same if you are going to read the same cookie in either scheme.

[ryanelian]

Awesome.

So setting the same CookieName is not enough?

Sorry, I haven't heard about TicketFormat before. I saw https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/compatibility/cookie-sharing but I don't really get what I am supposed to configure.

Mind providing code sample for this? Thanks again.

[Tratcher]

Just CookieName should be enough.

That said, with AutomaticAuthenticate and AutomaticChallenge removed from CookieAuthOptions, why do you still need two auth middleware? Nulling out the paths has never had any effect.

[ryanelian]

That said, with AutomaticAuthenticate and AutomaticChallenge removed from CookieAuthOptions, why do you still need two auth middleware? Nulling out the paths has never had any effect.

Oh did they in 1.1? TIL.

I thought if you don't set them as false / nulled out , they'll kick you to login / access denied path, which is not preferable for API-type Controllers. (You'd want instead just a status code response indicating that the request is unauthorized / forbidden)

I don't know, I've been using that technique since forever, never noticed if they don't have any effects anymore or something.

[Tratcher]

No, that behavior was caused by AutomaticChallenge = false, the middleware was being bypassed for challenges. Null paths were always set to defaults by the middleware.

I suspect that 401 status code was being set by the IISIntegration middleware, which always assumed windows auth was enabled (AutomaticChallenge = true). This is going away soon: aspnet/IISIntegration#371.

A different approach that would still work (without two middleware) is to use the events to control the behavior:

Security/src/Microsoft.AspNetCore.Authentication.Cookies/Events/CookieAuthenticationEvents.cs

Line 43 in 1f5a27e

if (IsAjaxRequest(context.Request))

[ryanelian]

A different approach that would still work (without two middleware) is to use the events to control the behavior:

public Func<CookieRedirectContext, Task> OnRedirectToLogin { get; set; } = context =>
{
    if (IsAjaxRequest(context.Request))
    {
        context.Response.Headers["Location"] = context.RedirectUri;
        context.Response.StatusCode = 401;
    }
    else
    {
        context.Response.Redirect(context.RedirectUri);
    }
    return TaskCache.CompletedTask;
};

Ohhh yesss, that's what I'm talking about. 👍 🌶 🔥

Will that behavior be enabled by default on the 2.0.0 Authentication Cookie?
So I don't need 2 separate authentication schemes for cookie return behavior after all?

EDIT: Oh I just remembered that header Location still redirects... Oh well.

Thank you for solution, I guess. At least I know it's possible. Or I'll just stop caring altogether about API controllers redirecting on authorization failure...

[Tratcher]

The Location header does not trigger redirects, the status code does.

[ryanelian]

Oh okay.

So to recap, the new cookie authentication scheme will not redirect when it's AJAX request, by default, but instead returns 401 when not authenticated, or 403 when access denied.
Therefore I don't need 2 different authentication schemes just to handle that behavior in 2.0.0.

Am I understanding that correctly?

Alrighty then, thank you guys. Great job over there, keep it up. 👍

[Tratcher]

Note 1.0 behaved the same way.

[ryanelian]

Huh... Now that's curious. I wonder why I did that in the first place then.

I vaguely remembered long ago that it bounced me to other page when my Angular service hits an unauthorized / access denied controller.

Oh well. Thanks for info.

[HaoK]

e940cdb