The Grand Auth Redesign of 2017

[HaoK]

Latest PRs:

• Options Options 2.0 Iteration 3 - Breaking change edition: Takeover IOptions Options#179
• HttpAbstractions: Auth 2.0: Add Auth Abstractions, Core HttpAbstractions#798
• Security: Iteration 4 - Using Auth 2.0/Options 2.0 packages #1170
• MVC: Update MVC to Auth 2.0 Mvc#6131
• Identity: Auth/Options 2.0 + Identity Identity#1119
• Music Store: Update to Auth 2.0 MusicStore#780
• SignalR: SignalR => Auth 2.0 SignalR#406
• IdentityService: https://github.com/aspnet/IdentityService/pull/63
• Templates: Templates => Auth 2.0  dotnet/templating#624

Fixes

• Dynamic scheme handler support: Add/Remove/Configure Authentication Middleware at Runtime #1132
• Named/multi tennant options Middleware Extensibility: Support "Multi-tenancy" In AuthenticationOptions (and more) #35
• RIP automatic Redesign automatic authentication choice mechanism #1061 Automatic Cookies challenge overridden by Windows Authentication since 1.1.0 HttpSysServer#284
• Signout does not throw in 2.0 Signout for google throws #1039

To be continued in: #1190

@Eilon @muratg @Tratcher @ajcvickers @blowdart

[RickBlouch]

I have read through the history for much of the Auth 2 issues and have browsed the code in the hoak/auth2 branch trying to get an early understanding of the new system. I realize it's still a work in progress so I may be too early and if that's the case just let me know, but since the "Named/multi tenant options #35 " is marked as close I'm hoping you can point me in the right direction.

Right now I am using something very similar to this post where the request pipeline is being forked for each tenant (based on hostname) and I am able to create tenant specific authentication middleware (among other tenant specific middleware setup) configurations based on tenant specific values retrieved from our database. More specifically we have scenarios where some tenants have one or two OIDC middleware configured and others may not have any.

I can see in the new codebase that this will not work the same way with Auth 2 and that's fine, but I couldn't figure out based on reading the various issues and browsing the new codebase exactly how I will replicate the above functionality. Can you point me in the right direction?

[HaoK]

There won't be any way to fork things since there's only a single service collection, but you should be able to register each using the tenant specific name similar to how the cookie name is being set in that post you mention, if you don't know the tenants at startup, can add dynamically schemes via the ISchemeProvider.AddScheme https://github.com/aspnet/HttpAbstractions/blob/dev/src/Microsoft.AspNetCore.Authentication.Abstractions/IAuthenticationSchemeProvider.cs#L56:

   services.AddGoogleAuthentication("Google-<tennant>", options => { });

You'll also have to challenge/authenticate using the new tenant specific names as opposed to just always "Google", but I imagine that shouldn't be too big of a change.

Does that sound like it will work for your scenario?

[CoskunSunali]

I have a scenario where I implement the things exactly the way @RickBlouch does.

The multiple-schemes solution does not sound like the best scenario - if I don't get it wrong.

The way @RickBlouch and I implement the things makes each tenant able to access only the services specific to itself but the way you suggest by schemes solving the issue requires each tenant to have access to all schemes even if they don't relate to it.

What is more, it requires (if I am not wrong) manually invoking the challenge/authenticate methods when needed as opposed to having a single scheme for each tenant's own pipeline using the same scheme name and having it automatically handled.

@HaoK , I have not really looked through the changes you made but the main complaint about the auth configuration was that we had to configure some of the things too early in the app life cycle. For instance we still did not know which tenant was being requested (lazy initialization) but we had to configure the token endpoint using a specific URL instead of tenant specific services and token endpoints based on the tenant host names.

We discussed the same thing with @PinpointTownes at aspnet-contrib/AspNet.Security.OpenIdConnect.Server#107 shortly. The issue does not provide much information but it should give you an idea. Otherwise I invite @PinpointTownes to this discussion.

The following quotation from @PinpointTownes's comments describes the issue very well, in my opinion.

Sadly, this won't work, as AuthenticationMiddleware calls IOptions<>.Options directly in its constructor (where you can't access the current request, since there's simply none 😄) and stores it as a singleton: https://github.com/aspnet/Security/blob/dev/src/Microsoft.AspNet.Authentication/AuthenticationMiddleware.cs#L26-L34

To support multi-tenancy, AuthenticationMiddleware's inheritors would also have to update their constructor, to avoid accessing the options instance too early. I guess we'd need a ValidateOptions directly in AuthenticationMiddleware to delay options validation.

[HaoK]

So far we have only enabled dynamically adding/removing schemes since its is the first building block needed for multi-tenancy.

To keep each tenant's ability to challenge "Google"/"Facebook" with the new stack, you should be able to accomplish this by replacing some combination of IAuthenticationService/IAuthenticationSchemeProvider/IAuthenticationHandlerProvider to resolve the appropriate tenant specific instance using the request.

The main idea was to make auth service based rather than middleware, so there should be a lot more extensibility/flexibility now

[RickBlouch]

There won't be any way to fork things since there's only a single service collection, but you should be able to register each using the tenant specific name similar to how the cookie name is being set in that post you mention, if you don't know the tenants at startup, can add dynamically schemes via the ISchemeProvider.AddScheme https://github.com/aspnet/HttpAbstractions/blob/dev/src/Microsoft.AspNetCore.Authentication.Abstractions/IAuthenticationSchemeProvider.cs#L56:

services.AddGoogleAuthentication("Google-", options => { });

Forking the pipeline was a pretty clean way to do things so I'm sad to see it go; this feels like a step backwards in that regard. From top to bottom, my pipeline could be unique per tenant which was great in terms of isolation. We deal with PCI and HIPAA so the more isolation the better. It's also not realistic to load all tenants at startup time, I can't imagine that would be the case for very many enterprise apps.

Just to confirm what you are suggesting, in order to dynamically add these schemes on the fly, I'm guessing I will have to have a step in my tenant resolution middleware that makes a call to GetSchemeAsync and checks if a scheme exists with my tenant based scheme name "Google-*****". If not, call AddScheme.

Does that sound like what you are anticipating? Will AddScheme be adding additional dependencies to my DI container with every call? At 1000-2000 tenants will that be a problem?

You'll also have to challenge/authenticate using the new tenant specific names as opposed to just always "Google", but I imagine that shouldn't be too big of a change.

I can inject an object that has tenant context so yes this can happen pretty easily, just something extra I need to remember to do that I didn't have to with a forked pipeline.

await _httpContextAccessor.HttpContext.Authentication.SignInAsync("Google-<tenant>", new ClaimsPrincipal(id), authInfo.Properties);

Does that sound like it will work for your scenario?

I don't think I have a good enough understanding of the new way to make that decision yet. I'm going to see if I can evaluate IAuthenticationService/IAuthenticationSchemeProvider/IAuthenticationHandlerProvider next.

[HaoK]

That sounds right at this point, that said, we will likely spend some cycles to have a 'blessed' way that we encourage for multi-tenancy, so things should get better. Make sure to be involved in that issue/PR when we start on that work. cc @blowdart