Remove Authentication property from WebApplicationBuilder and fix up middleware auto-registration

[captainsafia]

Part of #42481.

We've concluded that we'll remove any authentication-related APIs from the top-level interface of WebApplicationBuilder.

[davidfowl]

It would be good if we could avoid regressing by making this change also support auto adding middleware by detecting services.

[captainsafia]

Updated this to include changes to the registration of auth(n)/auth(z) middlewares.

[halter73]

😢 Is there another way to do this? Can we use a public service type as our marker?

[davidfowl]

I spoke to @captainsafia about this and I think we can cautiously allow IVT to Microsoft.AspNetCore but not between individual components.

[captainsafia]

Is there another way to do this? Can we use a public service type as our marker?

That's where I originally started, but @davidfowl mentioned that using a marker type would be a more reliable option. In fact, the authorization middleware already does this here:

aspnetcore/src/Security/Authorization/Policy/src/AuthorizationAppBuilderExtensions.cs

Lines 40 to 45 in 5c3a312

	if (app.ApplicationServices.GetService(typeof(AuthorizationPolicyMarkerService)) == null)
	{
	throw new InvalidOperationException(Resources.FormatException_UnableToFindServices(
	nameof(IServiceCollection),
	nameof(PolicyServiceCollectionExtensions.AddAuthorization)));
	}

This serves as a more reliable indicator in the event that users do something strange and register a public type in DI themselves (unlikely but ya never know).

We could've made these marker types public, but I think it pollutes the public API primarily for our benefit with little value to users.

[halter73]

My concern is that this makes it easier to consume internal APIs from the Microsoft.AspNetCore project in the future without realizing it. In many cases consuming an internal API from another project is a good signal it API should be public and after this change we'll lose that signal.

While no one else may ever use a public AuthenticationMarkerService in particular, I don't think the noise it adds is too onerous either. We can make it EditorVisibleNever like @Tratcher suggests.

[captainsafia]

Using EditorVisibleNever is a good recommendation. I'll go ahead and do that on the existing authorization marker type too.

While no one else may ever use a public AuthenticationMarkerService in particular, I don't think the noise it adds is too onerous either.

Perhaps, but I think it's the accumulation of decisions like these that pollutes an API.

Edit: Nevermind. I just realized that Chris's recommendation was to make these marker types public and use EditorBrowsable.Never.

In many cases consuming an internal API from another project is a good signal it API should be public and after this change we'll lose that signal.

Perhaps this removes the compile-time alert, but there are still other gates.

I would rather not use the marker types and use existing public ones then introduce public APIs with low value.

[davidfowl]

PUBTERNAL is back!

[captainsafia]

I don't see the problem with this either. It seems to be the simplest solution.

Yeah, that's where I started. It's a little ad-hoc but it involves far less ✨ controversy ✨ than this so 🚢

[captainsafia]

Went ahead and removed the IVT here. IMO, if we're choosing between introducing hidden, public types or using a non-marker service, I lean towards the later.

[davidfowl]

I think there are some very good usages of IVT here now that I’ve seen this.

[halter73]

I agree that IVT could be very convenient. I've long thought will make the WAB much cleaner if we were not restricted to using the public ConfigureWebHostDefaults API or being forced to add a public API that will ever only be used by WAB itself. I can probably be convinced that IVT is justifiable for Microsoft.AspNetCore from any assembly because it's the composition root or whatever giving it a special status.

We should discuss this in a meeting with everyone involved though. If we agree, we can go back to the internal marker service. I don't think it should hold up this PR.