How to Grant Admin Override Access in ASP.NET Authorization Policies?

One of the common requirements in enterprise applications is to give staff or administrators the ability to override normal authorization checks.

Instead of having regular users go through all the standard authorization rules, admins should have automatic access to everything—without you having to add special admin checks to every single requirement handler.

In this post, I'll show you how to implement this in ASP.NET using the policy-based authorization framework.

We'll build a mechanism that automatically grants staff and admins access to all policies and requirements by default, while still enforcing the rules for regular users.

I'll be using Amazon Cognito as the identity provider for this example, but this approach works with any identity provider you're using.

This post is part of my ASP.NET Core Series, and thanks to AWS for sponsoring it in my Cognito Series.

The Problem: Adding Admin Checks to Every Handler

Let's say you have a complex authorization setup with multiple policies and requirements.

Policy-Based Authorization with Multiple Requirements and Handlers

Learn how to build flexible authorization policies in ASP.NET Core with multiple requirements and handlers per requirement. We'll explore real-world scenarios including subscription tiers, educational access, user suspension, and geographic restrictions.

rahulpnath.com

Here's a typical scenario from the above blog post where you might have a policy that checks:

• Geographic access - User must be from an allowed region
• Subscription tier - User must have Premium or Basic subscription
• Institution type - User belongs to education or research institution
• Account status - User is not suspended

Each of these requirements might have multiple handlers, creating an OR condition within each requirement, while all requirements must succeed (an AND condition between requirements).

Now, your business wants admin users to bypass all these checks automatically.

The naive approach would be to add an admin check to every single handler:

public class PaidSubscriptionHandler : AuthorizationHandler<SubscriptionTierRequirement>
{
    protected override Task HandleRequirementAsync(
        AuthorizationHandlerContext context,
        SubscriptionTierRequirement requirement)
    {
        // Add admin check to EVERY handler
        if (context.User.IsInRole("Admin"))
        {
            context.Succeed(requirement);
            return Task.CompletedTask;
        }

        // Regular logic for non-admin users
        ...
    }
}

While this approach works it introduces more issues

1. Not scalable - You need to modify every existing handler
2. Error-prone - Easy to forget adding the check in new handlers
3. Hard to maintain - Admin logic is duplicated everywhere
4. Violates DRY - The same admin check repeated in dozens of handlers

There's a better way.

The Solution: A Single Handler for All Requirements

The policy-based authorization framework in ASP.NET Core supports a powerful feature: a single handler can handle multiple requirements.

Until now, we've seen handlers that inherit from AuthorizationHandler<TRequirement>, which creates a one-to-one relationship between handlers and requirements.

But you can also implement IAuthorizationHandler directly, which gives you access to all pending requirements in the authorization context.

This is exactly what we need for our admin override functionality.

Implementing the Admin Policy Handler

Here's the complete implementation of an admin handler that automatically succeeds all pending requirements:

public class AdminHandler : IAuthorizationHandler
{
    public Task HandleAsync(AuthorizationHandlerContext context)
    {
        if (context.User.IsInRole("Admin"))
        {
            // Admin succeeds ALL pending requirements
            foreach (var requirement in context.PendingRequirements.ToList())
            {
                context.Succeed(requirement);
            }
        }

        return Task.CompletedTask;
    }
}

Let's break down what this code does:

1. Implements IAuthorizationHandler - This is the base interface, not the generic AuthorizationHandler<T>
2. Checks for admin role - Uses IsInRole("Admin") to check if the user belongs to the Admin group
3. Loops through pending requirements - context.PendingRequirements contains all requirements that haven't been satisfied yet
4. Succeeds all requirements - Calls context.Succeed(requirement) for each pending requirement

The context.PendingRequirements - this gives you access to all requirements that are still waiting to be satisfied.

Like any authorization handler, you need to register it in your dependency injection container. In Program.cs, add:

builder.Services.AddSingleton<IAuthorizationHandler, AdminHandler>();

That's it. This single registration enables admin override for all policies and requirements in your application.

How It Works in Practice

Let's see this in action with a practical example. Assume you have this policy setup:

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("CanAccessDetailedWeatherData", policy =>
    {
        policy.Requirements.Add(new GeographicAccessRequirement());
        policy.Requirements.Add(new SubscriptionTierRequirement());
    });
});

And you have these handlers registered:

• GeographicAccessRequirementHandler
• PaidSubscriptionHandler
• EducationalInstitutionHandler
• SuspendedUserHandler
• AdminHandler

For regular users, the framework runs through each handler checking requirements. If all requirements are satisfied by their respective handlers, access is granted.

For admin users, even if they don't meet the regular requirements (wrong locale, no subscription, etc.), the admin handler kicks in and automatically succeeds all pending requirements, granting access.

The Special Case: Explicit Failures with context.Fail()

There's an important edge case to understand: explicitly failed requirements.

In some scenarios, you might want to explicitly fail a requirement using context.Fail():

public class SuspendedUserHandler : AuthorizationHandler<SubscriptionTierRequirement>
{
    protected override Task HandleRequirementAsync(
        AuthorizationHandlerContext context,
        SubscriptionTierRequirement requirement)
    {
        if (context.User.IsInRole("Suspended"))
        {
            context.Fail(); // Explicitly fail
        }

        return Task.CompletedTask;
    }
}

When context.Fail() is called, that requirement fails regardless of other handlers, even if another handler calls context.Succeed() on the same requirement.

When a user is in both Admin and Suspended groups:

1. Suspended handler → ❌ Calls context.Fail()
2. Admin handler → Succeeds pending requirements

Result: Access denied (explicit fail takes precedence)

Allowing Admin Override for Explicit Failures

To allow admins to bypass explicit failures, add the admin check in the failing handler:

public class SuspendedUserHandler : AuthorizationHandler<SubscriptionTierRequirement>
{
    protected override Task HandleRequirementAsync(
        AuthorizationHandlerContext context,
        SubscriptionTierRequirement requirement)
    {
        // Don't fail if user is admin
        if (context.User.IsInRole("Suspended") && !context.User.IsInRole("Admin"))
        {
            context.Fail();
        }

        return Task.CompletedTask;
    }
}

Good Practices for Using context.Fail()

Instead of calling context.Fail():

• Let handlers succeed or not - If a requirement isn't satisfied by any handler, it automatically fails
• Use multiple handlers - Different handlers can handle different conditions with the OR logic
• Explicit failures should be rare - Reserve context.Fail() for critical scenarios like suspended accounts

Avoid using context.Fail() in most scenarios. Only use it for exceptional cases where you need to explicitly deny access.

References

• Policy-based authorization in ASP.NET Core
• What should a handler return?