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?