Make it harder (or impossible) to have more than one auth provider have "automatic" challenges

[Eilon]

From discussion with @HaoK @Tratcher @blowdart and others, we suggest either:

• Try to detect this scenario at runtime and alert the developer that this is an unsupported scenario (having more than one “automatic” challenge registered).
• Or change how automatic challenges are registered so that only one auth provider per app pipeline can be automatic. For example, instead of each provider having its own bool setting, you would instead have one "global" setting (i.e. per-IAppBuilder) where you specify which auth protocol is the automatic one (and all others are not automatic).

[Tratcher]

Design details:

• There is a small subset of auth providers that can collaborate in automatic challenge mode because their challenges can stack without conflicting. E.g. Basic, Bearer, and Windows auth.
• Whatever we do should take into account Windows auth as provided by IISIntegration and WebListener. They don't directly derive from the Auth base classes in this repo, only the raw HttpAbstraction.Auth infrastructure. IISIntegration auth is enabled by default but already has a mitigation for this built in. WebListener auth is not enabled by default.

[HaoK]

We could try moving from the AutomaticChallenge bool on each options, to a single AutomaticChallengeScheme[s?] on SharedAuthenticationOptions, which would effectively make it impossible to mave multiple defaults by accident. We could even allow this to be an ordered list by priority to support firing off multiple challenges (Basic/Bearer/Windows) where it would stop once any 'succeeded'

The downside of this would be no longer being able to default any auth to true, so all apps would need to explicitly configure this new setting in Startup.cs (but we could hide this a bit in the templates at least by having Identity configure this inside of AddIdentity()

[Tratcher]

The most common scenario where people run into this is when their apps have both interactive and API controllers. Right now we tell people they should specify Bearer on all of their API controllers, but what if MVC could allow for two separate default policies, one for each kind of controller? Then you just put Authorize everywhere and not worry about the two crossing.

[HaoK]

This is already the guidance I thought, when mixing interactive and API, you have a Bearer policy for the API controllers, and a Cookie policy for the interactive, Authorize("Bearer") on one with Authorize("Cookie") on the other.

[Tratcher]

I meant that we could make [Authorize] smart enough to pick a policy based on the controller type so you didn't have to specify it everywhere, only in one central location.

Edit: Like splitting AuthorizationOptions.DefaultPolicy into DefaultApiPolicy and DefaultInteractivePolicy

[leastprivilege]

Yes please add more "automatic magic" - didn't that bring us here in the first place?

[Tratcher]

@Eilon does the combine WebApi/MVC still make a clear distinction between API controllers and interactive controllers?

[leastprivilege]

no.

[HaoK]

I don't think it makes sense for Authorization to have any notion of interactive/API, once you have something like two 'default' policies, that doesn't seem 'default' at all. Name them if you want specific behavior i.e. [Authorize] + [Authorize("Interactive")]

[Tratcher]

That's our current guidance and it clearly isn't working for people.