Unable to workout which AuthorizationPolicy failed

[slaneyrw]

Describe the bug

I have multiple authorization policies, each testing a specific business condition ( i.e. presence of a claim on the user).

The AuthorizationMiddleware is combining all the requirements into a single AuthorizationPolicy so when an endpoint is decorated with more than one Authorize attribute I cannot tell which of the original policies failed, there is no way to tie the failed requirement back to the original policy.

I need to send the user to a different endpoint depending upon which policy failed.

The IAuthorizationService instance only gets a list of requirements, it cannot work out the policy it came from.
The IPolicyEvaluator may get a list of pending requirements, but that's from the combined AuthorizationPolicy, cannot tie it back to the original policy. If a handler explicitly calls Fail(), the IAuthorizationService doesn't returns which requirement failed in it's Pending list, we're even more stuck!

The only thing I can think of is to iterate though all of the policies on the AuthorizationOptions and match the requirement by instance... assuming the only source of policies is AuthorizationOptions.

Possibilities I've considered

1. Override IPolicyEvaluator.
   If the authorizations service returns a failed authorization resulr, try to find a matching AuthorizationPolicy for each pending requirements from the list of authorization policies in the AuthorizationOptions instance, comparing the requirement by object reference. If more than 1 pending requirement remains, which policy takes precedence. If a requirement instance is duplicated in more than 1 policy, I cannot workout which one. Add the failed policy to the HttpContext items so the scheme's ChallengeAsync/ForbidAsync handlers know what to do.

2. Replace AuthorizationMiddleware
   Execute policies from the endpoint metadata individually instead of combining. Supply the policy on the ChallengeAsync/ForbidAsync in the authentication properties
   Duplicates all the logic from the existing AuthorizationMiddleware.
   Inconsistent with the AuthorizationFilter implementation which appears to be hardcoded into AuthorizationApplicationModelProvider but if I'm using Endpoint Routing then it doesn't appear to matter.
   Allows me to execute Policies that don't require an authenticated user before evaluating IAllowAnonymous logic.

Further technical details

• ASP.NET Core version: 3.0.0

[blowdart]

Can I ask why it's important to know what policy failed? Are you going to change the UI based upon it?

[slaneyrw]

Can I ask why it's important to know what policy failed? Are you going to change the UI based upon it?

The application needs to redirect to different URLs depending on which policy failed.

[blowdart]

That's not really a scenario we considered if I'm honest. Failure of authorization either redirects to a "You're not logged in" or a "You're not allowed" page and that's it. The details didn't matter.

@HaoK can you think of any way to do this?

[slaneyrw]

I ended up replacing the default middleware. Mine iterates over each policy and when the first fails it calls either ForbidAsync or ChallengeAsync ( depending on whether the policy had an auth scheme - same logic as the real middleware ). I also supply the current policy name as parameter in the AuthentcationProperties instance I build and pass to either method above.

Now the Authentication scheme handler knows which policy failed by querying the AuthenticationProperties on the HandleChallengeAsync/HandleForbiddenAsync override.

To close the loop on my need above, this scheme handler has a configured options that have as a dictionary of handlers, keyed by policy name, that generates a response. The handler gets given the current HttpContext so if a handler can use RequestServices if required

• Return 401 / 403
• Redirect to preconfigured URL
• Forward to another authentication scheme's handler
• etc

[elonmallin]

Would also like to be able to do this but it seems rather complicated to replace the default middleware.

I found another issue from a long while back that had the same problem. It's closed however and not sure exactly what the conclusion was.

Is there any plan to introduce some easy way to do this? Something like:

// Startup.cs
app.UseStatusCodePagesWithReExecute("/error/{0}");

// ErrorController.cs
[Route("{statusCode}"), HttpGet]
public IActionResult StatusCodeError(string statusCode)
{
  var policyAuthService = ... // Get some ASP.NET Core auth policy service
  if (policyAuthService.FailedPolicies.ContainsType(typeof(AdminRequirement) && statusCode == "403")
  {
    // Return a message with why we don't have access.
  }
}

Or is this possible already somehow?

[slaneyrw]

Reviewed #21116, but still can't work out which policy failed so moving the result handler doesn't make the above scenario any different.

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!