Discussion for Auth 2.0

[HaoK]

Related discussion thread of issues/questions about aspnet/Announcements#262

[joeaudette]

Hi,

In the announcement for the breaking changes you said:

"In 1.0, it was possible to configure different Authentication middleware with branching, this is no longer possible with a single middleware and shared services across all branches. A workaround could be to use different schemes/options for each branch."

I am facing this problem and would appreciate some elaboration on specifically how I can use different schemes per branch. My solution can provision new tenants at runtime, so iterating through tenants in startup to add schemes is not a solution for me.

Wondering if you could provide some guidance on what I could override to dynamically resolve schemes and options per request. PostConfigureCookieAuthenticationOptions, looks like a potential candidate that might allow me to do that, but not sure if that allows me to adjust the options per request. IAuthenticationSchemeProvider sounds like another potential thing to implement.

Could you offer a suggestion of the right thing to implement/override to achieve a way to resolve auth scheme/options on a per request basis?

Thanks in advance for any advice!

[HaoK]

Alternatively you could also try replacing the IAuthenticationHandlerProvider to return the appropriate instance for your branch and use the same name in each branch. The default implementation of this is just a scoped dictionary cache: https://github.com/aspnet/HttpAbstractions/blob/dev/src/Microsoft.AspNetCore.Authentication.Core/AuthenticationHandlerProvider.cs

If you had a implementation that was branch aware, that should be a step in the right direction. You'll still have to figure out how to resolve the appropriate options, but you could do that via plugging in your own IOptionsMonitor that is branch aware.

[joeaudette]

Thank you! Really appreciate the prompt response! I will give IAuthenticationHandlerProvider a try.

Can you tell me what is the purpose of IOptionsMonitor? what is it used for? I'm familiar with IOptions of T but IOptionsMonitor is new to me.

[HaoK]

Its basically the same thing, it just adds the ability to name options IOptionsMonitor.Get(authenticationScheme) is what you will need to implement

[joeaudette]

Thanks!
Wondering also about cookie name, in my current 1.1 solution I support tenants based on the first folder segment so for that I have been using different auth scheme names with the cookie named the same as the auth scheme so that is is possible to login to multiple tenants without cookies stepping on each other. ie since the host name is not different per tenant I have to account for the fact that the browser will share cookies for the host name and use different cookie names
Can we still configure different cookie names or will they be named after the authscheme so it would be sufficient to use different auth scheme names per tenant to get different named cookies?

[HaoK]

You can configure them however you like the underlying options haven't changed that much

[joeaudette]

Awesome, thanks very much! Will let you know how it goes or if I run into any troubles, working on the netcore20 branch in my open source project here https://github.com/joeaudette/cloudscribe , just got it to build but mainly by commenting out the broken bits, now I will try to get it working again following your advice.

[valeriob]

I'm trying to bring our owin authentication code to aspnetcore 2.0, so much stuff have changed !
I hope i can bring there same functionality back, i'll give feedback on it.
At first impact i see too much use of new() generic constraint, it's kinda a bad smell to be honest, i think the framework should not instantiate anything but let the user build his types providing the right hooks, like owin did, i see no reason why the framework should instantiate AuthenticationSchemeOptions and AuthenticationHandler.

[Banashek]

So I'm just trying to add a simple claim based on a boolean column in my ApplicationUser table in my database. This seems prohibitively difficult.

I set up an IClaimsTransformation implementation which would get the user from the database and add the claim depending on the column value. I'm guessing because it's registered as a transient service is the reason that it's being called every single request, so it seems to be the wrong approach in my case.

I might not be approaching the problem correctly, but I'm not sure what the correct way to solve this problem is. All I want to do is check if a ApplicationUser.IsEnabled property is true in my authorization.

I kinda just want a simple function isUserEnabled, but feel like I have to go through a SpringBeanComparerFactoryFacadeAdapterFactory to check this.

I'll put the problem clearly here:
How do I authorize a user based on a boolean database column?
Is there a way to do it without hitting the database on every request? (claims seem to be the right approach here)
If claims are the right approach, how do I add a claim to a user? (All the auth docs talk about checking claims, but never adding them)
If I need to update a claim on my user, how can I do this? (Say I want to enable a disabled user after they update their payment method)

Thanks for any advice available.

[joeaudette]

@HaoK thanks to your previous help I managed to get my multi-tenant cookie auth working again. Now I am moving on to working on getting my multi-tenant social auth working and could use more advice about what to implement in order to resolve correct MicrosoftAccountOptions per tenant. I am working against preview2 and I see there are additional changes after preview2 such as use of IOptionsSnapshot in preview2 vs IOptionsMonitor in the current code. Since I am targeting preview2 for the moment, I was able to handle the mutlit-tenant cookie auth by implementing a custom

IOptionsSnapshot<CookieAuthenticationOptions>.

Since that worked I figured a similar solution should work for Microsoft Account Authentication by implementing a custom

IOptionsSnapshot<MicrosoftAccountOptions>

But currently I'm getting an error:

    System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.AspNetCore.Authentication.OAuth.OAuthHandler`1.BuildChallengeUrl(AuthenticationProperties properties, String redirectUri) at Microsoft.AspNetCore.Authentication.OAuth.OAuthHandler`1.<HandleChallengeAsync>d__11.MoveNext()

I had a similar null reference when I first implemented the cookie auth but was able to solve it by taking a dependency on

IPostConfigureOptions<CookieAuthenticationOptions>

and calling PostConfigure on my options which seemed to solve whatever was null on my cookie options.

But I don't see anything similar to that to call for my MicrosoftAccountOptions, there exists MicrosoftAccountConfigureOptions but it is internal so I cannot use it even if it would solve the problem.

Wonder if you could shed any light or advice on how best to override the options per request based on my resolved tenant. Mainly I need to adjust the clientid, clientsecret, and callbackpath per tenant.

[joeaudette]

@HaoK it looks like what is null on my MicorosoftAccountOptions is StateDataFormat

What would be the correct way to populate that?

[HaoK]

You need to something like https://github.com/aspnet/Security/blob/dev/src/Microsoft.AspNetCore.Authentication.OAuth/OAuthPostConfigureOptions.cs

[joeaudette]

@HaoK thank you! that got me past the null error, but now after redirecting back from microsoft I get

AggregateException: Unhandled remote failure. (OAuth token endpoint failure: Status: Unauthorized;Headers: Cache-Control: no-store, no-cache

any ideas about that?

[joeaudette]

wait it is saying invalid client, I thought I was using credentials that already worked, I will double check first that it works in my 1.1 branch as it did before

[joeaudette]

@HaoK thank you again, that got it working! Somehow my client secret got corrupted in the db but once I fixed that I was able to get it working! Really appreciate all your help!

[valeriob]

I'm starting to get the new model 😄 , it handles challenges in a more clean way, but:

• The whole injecting singletons in extension methods
  _services.TryAddEnumerable(ServiceDescriptor.Singleton<IPostConfigureOptions, OAuthPostConfigureOptions<TOptions, THandler>>());
  and the concept of IPostConfigureOptions is very bad practice, too complex and hard to get, you should not need those.
  Most of the time is used to get an instance of IDataProtectionProvider dataProtection, but you should get it on the middleware constructor instead.

• The AuthenticationSchemeOptions.Events Property is Object and not generic, it smells more and more down the line with a lot of casting on specific implementations, i do not see any reason for that.

All in all, good job !

[valeriob]

I have a question about IClaimsTransformation.
In owin/katana, the OpenIdConnect middleware exposes a function OpenIdConnectAuthenticationNotifications.AuthorizationCodeReceived that allowed to craft a AuthenticationTicket with an ClaimsIdentity where i could query the database just once when the user authenticate and add custom claims.
In the new model OnAuthorizationCodeReceived does not allow that and IClaimsTransformation.TransformAsync it's called for every request, so i would hit the database on every request.
I would like to add custom claims before the SignIn (so they get persisted on the cookie for example), how can i do that ?
Thanks

[HaoK]

Why can't you continue to use OnAuthorizationCodeRecieved?

[valeriob]

Hi @HaoK
thanks it works ! i can replace the AuthorizationCodeReceivedContext.Principal.

Still i do not think it's a very good design, those functions are called Events, and they look like side effect free functions, instead you can change "something" on the input parameters and have some side effect.
To see what you can affect you have to look at source code of the caller to understand what's going on and what you can do :

I would call those Callbacks, and make the side effect explicit on the return type, so you are sure on what you can affect.

[kevinchalet]

Still i do not think it's a very good design, those functions are called Events, and they look like side effect free functions, instead you can change "something" on the input parameters and have some side effect.

That's exactly how good old events/event handlers work 😅

E.g https://msdn.microsoft.com/en-us/library/system.componentmodel.canceleventargs(v=vs.110).aspx

[mclasson]

@Banashek You are correct. Just add a new Claim. Look at an example here https://marcusclasson.com/2017/08/03/adding-authentication-in-aspnetcore-2-0/ At the bottom I add a custom claim (like user id)
Works in 2.0

[plaisted]

@joeaudette

I recently went through the same issues you were having where I needed different authentication for each branch. We have a multi-tenant setup where each branch/tenant would have their own certificates etc for JwtBearer.

I ended up with a different approach than was discussed here due to their comment "A workaround could be to use different schemes/options for each branch" and not seeing this thread until after completing the work. I thought I'd post here in case others are having issues as there isn't much guidance out there.

I set up all my different authentications for each branch with a specific scheme name:

foreach (var scheme in mySchemes)
{
    services.AddJwtBearerAuthentication(scheme.Name, options => { // scheme specific options here //});
}

I then created a custom IAuthenticationSchemeProvider that was identical to the default implementation except for injecting a IHttpContextAccessor to the constructor and changing all of the GetDefaults to be branch aware like:

//naive example:
public Task<AuthenticationScheme> GetDefaultAuthenticateSchemeAsync()
{
    var schemeToUse = _context.HttpContext.Request.Path.Value.Split('/')[1];
    return GetSchemeAsync(schemeToUse);
}

This allowed me to keep everything else with the default implementation and have each individual scheme be unaware of any custom setup. I haven't fully vetted this as it's using Preview2 and is a POC but appears to be functioning properly.

[joeaudette]

Having some issues updating from preview2 to rtm. Where can I find the code for the default implementation of

IOptionsMonitor<CookieAuthenticationOptions>

?

[joeaudette]

nevermind, it is generic, I forgot https://github.com/aspnet/Options/blob/dev/src/Microsoft.Extensions.Options/OptionsMonitor.cs

[sireza]

Having issues porting our app to .NET Core 2.0

Background: This is an API app with Swagger access. The app uses Azure AD as provider
Supported Use Cases:

• Browser access via Swagger - Challenged by OpenIDConnect
• Direct access from another application - Other app includes bearer token on the header

The following works as above pre 2.0:

            app.UseCookieAuthentication(new CookieAuthenticationOptions
            {
                AuthenticationScheme = CookieAuthenticationDefaults.AuthenticationScheme,
                AutomaticAuthenticate = true,
                AutomaticChallenge = true
            });

            app.UseOpenIdConnectAuthentication(new OpenIdConnectOptions
            {
                AutomaticChallenge = true,
                AutomaticAuthenticate = true,
                ClientId = Configuration["Authentication:ClientId"],
                Authority = Configuration["Authentication:Authority"],
                AuthenticationScheme = OpenIdConnectDefaults.AuthenticationScheme,
                SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme
            });

            app.UseJwtBearerAuthentication(new JwtBearerOptions
            {
                AutomaticChallenge = true,
                AutomaticAuthenticate = true,
                Audience = Configuration["Authentication:ClientId"],
                Authority = Configuration["Authentication:Authority"],
                AuthenticationScheme = JwtBearerDefaults.AuthenticationScheme
            });

            // Requires authentication to use swagger
            app.Use(async (ctx, next) =>
            {
                if (ctx.User?.Identity != null && ctx.User.Identity.IsAuthenticated)
                {
                    // If you're authenticated, proceed
                    await next();
                }
                else
                {
                    // If you're not authenticated, do not proceed
                    // and issue an authentication challenge
                    await ctx.Authentication.ChallengeAsync();
                }
            });

Tried the following after ported to 2.0

In ConfigureServices(...)

                services.AddAuthentication(options =>
                {
                    options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                    options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                    options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
                    
                })
                .AddCookie(options =>
                {
                    options.Cookie.SecurePolicy = CookieSecurePolicy.SameAsRequest;
                    
                })
                .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>
                {
                    options.Audience = Configuration["Authentication:ClientId"];
                    options.Authority = Configuration["Authentication:Authority"];
                    
                    
                })
                .AddOpenIdConnect(options =>
                {
                    options.ClientId = Configuration["Authentication:ClientId"];
                    options.Authority = Configuration["Authentication:Authority"];
                    options.ClientSecret = Configuration["Authentication:ClientSecret"];
                    options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                    options.ResponseType = OpenIdConnectResponseType.IdToken;
                });

In Configure(...)

            app.UseAuthentication();
            //Requires authentication to use swagger
            app.Use(async (ctx, next) =>
            {
                if (!env.IsDevelopment() || (ctx.User?.Identity != null && ctx.User.Identity.IsAuthenticated))
                {
                    // If you're authenticated, proceed
                    await next();
                }
                else
                {
                    // If you're not authenticated, do not proceed
                    // and issue an authentication challenge
                    await ctx.ChallengeAsync();
                }
            }); ```

What am I missing?

[davidfowl]

What behavior are you expecting? There's no more automatic* anything in 2.0, you can only have a single "default scheme".

[JoshuaBelden]

I'm hoping someone can give me some guidance with a question I posed here, https://stackoverflow.com/questions/47804064/what-is-the-equivalent-of-useoauthbearerauthentication-in-an-asp-net-core-2-appl.

I have a resource server using ASP.NET Core 2 that needs to be configured to read an access token that's an encrypted AuthenticationTicket. Previously, I could configure bearer auth with .UseOAuthBearerAuthentication(new OAuthBearerAuthenticationOptions(). The only thing I see equivalent to this is .AddJwtBearerAuthentication but the format of my token is not Jwt.

Is there something more generic I can use?

[bungeemonkee]

Maybe this is a dumb question but can I ask why? It seems this new design adds complexity while removing the ability to gracefully handle several use cases the previous design handled well. The only arguable improvement seems to be the introduction of the unified auth middleware. But providing an abstract auth middleware base class for implementors to inherit could have encapsulated that shared functionality without adding this extra complexity or dropping support for existing use cases. What am i missing?

[Tratcher]

@bungeemonkee because maintaining the token server was costly and the old bearer middleware primarily interfaced with that token server. Also, JWTs and OpenIdConnect have gained broad adoption.

See https://github.com/aspnet/Security/issues/1235 for tracking this request.

[brockallen]

because maintaining the token server was costly

In addition, there are several commercial and open source token servers that are feature rich and are being maintained. Here's one such open source token server that's even recommended by the ASP.NET team: http://identityserver.io/

[MV10]

@HaoK Maybe this isn't the right place to ask, but I keep seeing statements like this (in this thread and elsewhere):

You'd retreive the identity via context.AuthenticateAsync("pf"), and then construct a new ClaimsPrincipal with this, and merge the existing context.User.Identities in and set context.User to that merged principal.

What I can't figure out is why ASP.NET works so hard to avoid a principal with multiple identities -- that's the whole point of separating the principal from its identities. I'm new to Identity, but as I dig into it, I've begun to think that Identity persistence is completely broken -- claims are directly associated to the user (principal), rather than being grouped by identities (which should then be associated with the user / principal). I'm starting to get the impression that the same mistake extends further into ASP.NET than just Identity persistence.

I recognize the typical use-case probably just needs one active identity, but that would work in a correct principal / identities / claims relationship, whereas the current single-identity assumption more or less rules out a multiple-identity scenario.

[HaoK]

Not sure what you are specifically talking about. When we say 'identity' we are typically referring to the ClaimsPrincipal for the user. Both the authentication stack and asp.net core identity are about producing claims principals as the core responsibility of the authentication system is having named 'authentication schemes' producing ClaimsPrincipals.

For Identity, there's a IUserClaimsPrincipalFactory interface: https://github.com/aspnet/Identity/blob/dev/src/Microsoft.Extensions.Identity.Core/IUserClaimsPrincipalFactory.cs. The auth stack is a bit more involved, but you can dig into that in: https://github.com/aspnet/HttpAbstractions/blob/dev/src/Microsoft.AspNetCore.Authentication.Abstractions

[MV10]

In the real world, everyone has lots of different identities:

• Principal: John Doe (person)
  • Identity: Driver's License
    • Claims: name, address, birthdate
  • Identity: Passport
    • Claims: name, birth location, passport number

If I build a site that has site-specific user information (maybe a local username, an account type, join-date, that kind of thing), that information is the site-specific identity for that principal -- the user. After the user also authorizes my site to post to Facebook on his behalf, it's still the same user / principal, he has just picked up an additional identity (Facebook auth):

• Principal: John Doe (user)
  • Identity: My Site Data
    • Claims: username, account_type, join_date
  • Identity: Facebook
    • Claims: email, public_profile, user_friends

But unless I'm overlooking something, ASP.NET Identity persistence doesn't seem to have the ability to store the details of a single principal (user) with multiple identities, each with their own claims. All that stuff exists in the Security assemblies (ClaimsPrincipal has the Identities collection, etc) but it seems to have just been thrown out the window by the time we get into ASP.NET Identity (again, at the persistence level ... it looks like it would be possible above that level if we wanted to roll our own persistence code).

I actually have to implement that exact scenario relatively soon. A site I'm working on will have a lot of site-specific user information, but the users will also be authorizing the site to do things on their behalf using a pretty large number of third-party sites. I'm pretty sure we're just going to roll our own via IdentityServer, but I'm still trying to understand the ASP.NET Identity model, I'm sure it will come up again elsewhere.

[HaoK]

I already gave you the link to the interface that's responsible for building the ClaimsPrincipal in identity, if your app wants to build multiple ClaimsIdentities in the principal, just plug in your own UserClaimsPrincipalFactory and you are in full control.

[MV10]

I understand I can build my own. I was hoping to learn why the concept of multiple identities per principal is not supported by ASP.NET Identity's persistence model.

[HaoK]

Identity is mostly focused on saving user data, you can build whatever authentication data structure you want from that via the ClaimsPrincipalFactory. Identity is not designed around persisting ClaimsIdentity/Principals, its about storing user data, which is typically used along with other things to produce the ClaimsPrincipals used for authentication.

[davidfowl]

@MV10 you know IdentityServer uses ASP.NET Core Identity to store user information?

[MV10]

@davidfowl It can, yes ... but we're also avoiding EF dependencies, so neither out-of-the-box implementation was an option for us.

@HaoK Thanks. Mostly I wanted to confirm I wasn't overlooking something. The docs about this stuff are kind of all over the place (probably another reason we're going with Identity Server, their start-from-empty Quickstart walk-throughs make it a breeze to understand all the moving parts).

I appreciate the discussion.

[timdoke]

I'm following the example from JwtBearerHandler while using an internal token generator. I'm having problems with the OnAuthenticationFailed callback. Basically, without throwing an error in here, the pipeline is allowed to continue to execute the controller code despite an error http status code being set.

If I do throw an error in that callback, I have two problems.. The first is that it gets wrapped into a 500 error (because anything done with the context, seems ignored and thus the default error handler gets called -- I also tried disabling developer exception page to no avail). Secondly, I can't use an errorFilter to try to handle the error (though I think this is intentional). I've tried using app.UseStatusCodePages and combinations thereof. I do not want to do a redirect to an error controller through the error handling middleware as we'd then lose the context of the request.

Can someone give me a recommendation on how to fix these? Thanks!

[timdoke]

It seems like some of the problems I linked to above were fixed by adding a Context.ForbidAsync before AuthenticateResult.Fail(with the exception). However, it does not work in Swagger -- swagger just shows no response with no status code. Also, it executes twice for some reason -- one thing I noticed on the second execution, was that the the c.Response.HasStarted was true in the OnAuthenticatedFailed callback. The first time, it was false. Definitely seems like a problem.

@HaoK can you tell me if any of these problems were fixed with netcoreapp2.1?

[Tratcher]

@timdoke I agree, that flow control is busted. I've filed #1613.
Throwing an exception is your best bet at the moment. You can combine that with an inline exception handler like this: https://github.com/aspnet/Diagnostics/blob/f90337c1a6d5edd0cfe55466e3f544f3be047917/samples/ExceptionHandlerSample/Startup.cs#L16-L36

[timdoke]

Great, thanks @Tratcher. I added an additional few things I was noticing on this stackoverflow post.. https://stackoverflow.com/questions/48327456/netcoreapp2-0-swagger-custom-authentication-failure-gives-no-result. Regarding your solution, I was under the impression that with authentication handlers, errorFilters and error middleware are ignored. Isn't the above just an error middleware (plus, i need to be able to get the correct http status code, so it can't be a catch all?)? I appreciate the response..

[Tratcher]

Error middleware should work fine so long as you put them before UseAuthentication. MVC error filters don't work because your error happens outside of MVC.

500 is the expected error code for internal exceptions. What else did you have in mind?

[HaoK]

So JwtBearer's OnAuthenticationFailed is a ResultContext https://github.com/aspnet/Security/blob/dev/src/Microsoft.AspNetCore.Authentication.JwtBearer/Events/AuthenticationFailedContext.cs which means it doesn't support control flow.

In 2.0 Only context's that derive from
https://github.com/aspnet/Security/blob/dev/src/Microsoft.AspNetCore.Authentication/Events/HandleRequestContext.cs

Or

https://github.com/aspnet/Security/blob/dev/src/Microsoft.AspNetCore.Authentication/Events/RemoteAuthenticationContext.cs

support control flow.

[timdoke]

@Tratcher from the sample, it looked like I should be able to handle this authentication failure inside the OnAuthenticationFailed callback. It is also incredibly unclear how I'm supposed to know to put that middleware exception handler before UseAuthentication..

[Tratcher]

Which sample? The one in Security is out dated.

[timdoke]

@Tratcher Is there a new sample? I'm checking the one in Security..

[Tratcher]

No, part of #1613 is to update the sample.

[nicodewet]

I was wondering if anyone out there has a working ASP.NET Core 2.0 Web API (e.g. the Todo sample app) sample app with AWS Cognito as the identity server? Not looking for a tutorial, just working app where just the config needs to be changed (e.g. options.Authority)

Update: figured it out, quite simple in the end (as you'd expect), I'll post a sample / skeleton ASP.NET Core 2.0 Web API to github as soon as I get a chance (in the mean time happy to help anyone else out - just shout)

[aspnet-hello]

We periodically close 'discussion' issues that have not been updated in a long period of time.

We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.

[los93sol]

How does this work behind a reverse proxy and AddFacebook now? I have a scenario where my proxy does ssl termination and the app is running in a container on http. Previously, app.UseForwardedHeaders would resolve the issue, but it's called too late now so doesn't seem to work anymore.

[Tratcher]

Called too late?

Note we don't track closed issues. Please open a new issue with more detail about your Startup.

[los93sol]

Nvm, figured it out, useforwardedheaders was just more sensitive than I expected. I included an extra header that the proxy didn’t forward...