Innovabit.DotNet.Interceptors.Authorization.Abstractions 2.0.117

Innovabit.DotNet.Interceptors.Authorization.Abstractions

Declarative authorization for Innovabit.DotNet.Interceptors via [Authorized] and [RequirePermission]. This is the provider-agnostic base: it ships the interceptor, the attributes and the IAuthorizationEvaluator abstraction. Pick a provider — or write one — to decide how a caller is checked:

• Innovabit.DotNet.Interceptors.Authorization.AspNetCore — HttpContext.User, policies, roles and permission claims.

Why on the service and not only the controller

A rule on a controller action holds for calls that arrive over HTTP. Put it on the service and it holds for all of them: the same operation invoked from a background job, a message handler, a gRPC endpoint or another service is checked the same way, and the rule lives next to the thing it protects.

Usage

services
    .AddInterceptors()
    .AddAspNetCoreAuthorization();       // or .AddAuthorizationEvaluator<MyEvaluator>()

services.AddScopedWithInterception<IRefundService, RefundService>();

public class RefundService : IRefundService
{
    [Authorized(Policy = "finance")]
    [RequirePermission("orders.refund")]
    public Task<Refund> RefundAsync(Guid orderId, CancellationToken cancellationToken) { ... }
}

The attributes

Both work on a method and on a class, where they apply to every method. A method-level [Authorized] replaces the class's, so a method can pick its own policy; [RequirePermission] accumulates, so a method can never shed a permission the class demands. Put them on the implementation, not the interface — the interceptor reads the concrete method the proxy stands in front of.

Named [Authorized], not [Authorize], on purpose: a web application usually has Microsoft.AspNetCore.Authorization in scope too, and two attributes with the same short name in one file is an ambiguity nobody needs.

What a refusal looks like

Both derive from AuthorizationException, so you can catch either the distinction or the family. The message names the operation and what it required. The method is never reached on a refusal.

Ordering

The interceptor runs at InterceptorOrders.Authorization (75): inside auditing (50) and outside validation (100). Both positions are deliberate — a refused call is still recorded as an attempt, and the answer to "may you call this" never depends on whether the arguments happen to be valid.

Writing an evaluator

Only your application knows where the caller comes from, so that is what a provider supplies:

public sealed class WorkerAuthorizationEvaluator : IAuthorizationEvaluator
{
    public ValueTask<AuthorizationOutcome> EvaluateAsync(
        AuthorizationRequirement requirement, CancellationToken cancellationToken = default)
        => new(requirement.Permissions.All(CurrentJob.Grants.Contains)
            ? AuthorizationOutcome.Allow()
            : AuthorizationOutcome.Deny("the job does not grant that permission"));
}

services.AddInterceptors().AddAuthorizationEvaluator<WorkerAuthorizationEvaluator>();

Return an outcome rather than throwing: the interceptor turns it into the exception, so the message reads the same whichever evaluator produced it. Unauthenticated and Deny are separate precisely so the caller can tell the two apart.

Registering the interceptor without an evaluator makes resolving an intercepted service fail. That is on purpose: a security check that silently does nothing is worse than no check at all.

License

MIT