Your initial statement in the noted decision is not entirely true. Although your new solution may achieve your original goal, it is still possible to get around the original error by retaining the AuthorizationHandler logic - provided that you have handlers for the basic authentication scheme, even if they are functionally skeletons.
Generally speaking, the handlers and authentication schemes are designed to establish + identity verification, which makes them necessary for the work of authorization handlers / policies, since they work on the assumption that the identity is already established.
ASP.NET Dev Haok summarizes this best here: "Authentication today does not know about authorization at all, it only cares about creating a ClaimsPrincipal for each scheme. Authorization should be somewhat aware of authentication, so AuthenticationSchemes in a policy is a mechanism for you to associate a policy with the schemes used to build an efficient application principal for authorization (or it just uses the default httpContext.User for a request that relies on DefaultAuthenticateScheme). " https://github.com/aspnet/Security/issues/1469
In my case, the solution I'm working on provided my own implicit identity concept, so we didn't need authentication schemes / handlers - just header markers for authorization. Thus, until our concepts of identity change, our header token authorization handlers that apply policies can be bound to the skeletons of scheme 1 to 1.
Endpoint Tags:
[Authorize(AuthenticationSchemes = "AuthenticatedUserSchemeName", Policy = "AuthorizedUserPolicyName")]
Startup.cs:
services.AddAuthentication(options => { options.DefaultAuthenticateScheme = "AuthenticatedUserSchemeName"; }).AddScheme<ValidTokenAuthenticationSchemeOptions, ValidTokenAuthenticationHandler>("AuthenticatedUserSchemeName", _ => { }); services.AddAuthorization(options => { options.AddPolicy("AuthorizedUserPolicyName", policy => {
Both the empty authentication handler and the authorization handler are called (similar to the setting for the corresponding OP messages), but the authorization handler still enforces our authorization policies.
source share