Skip to Content
IdentityServer

As OpenID and OAuth is for identity, AuthZen (https://openid.net/wg/authzen/) is for Authorization

For the last 20+ years, we have had protocols that allow the centralisation of Identity verification, initially SAML and then OAuth/OpenID Connect. Authorisation over this time has had no standard way for applications to obtain fine-grained access decisions from a central authority. In 2024, a group of authorisation vendors came together to develop a wire format for doing just that. It's called AuthZen and has now been approved by the OpenID Foundation.

Rock Solid Knowledge participated in many of the interop sessions, demonstrating its Enforcer authorisation product was compatible with AuthZen. We have subsequently created a free, open-source library for .NET developers to use to make AuthZen requests from their applications to any AuthZen-compatible authorisation engine. 

This article walks you through an application we developed to demonstrate how easy it is to add AuthZen authorisation to your .NET application.

Overview

This document walks you through how we've integrated AuthZen authorization into an employee expenses web application using the Rock Solid Knowledge AuthZen NuGet package. The policy server is already set up and running, using Rock Solid Knowledge's Enforcer product.

The sample code includes two projects

  • AuthZenPolicyServer
  • WebApp

To run this solution, you will need to run both the AuthZenPolicyServer and the WebApp.  To run the AuthZenPolicyServer you will need to obtain a free demo license from here.

The Razor pages in the WebApp delegate to an authorization service of IAuthorizeExpenseClaimActions. There are three implementations

  • AllowAllAuthorizeExpenseClaimActions
  • AuthZenAuthorizeExpenseClaimActions
  • DenyAllAuthorizeExpenseClaimActions

The AuthZenAuthorizeClaimActions requires the Rock Solid Knowledge NuGet package to perform AuthZen requests to an AuthZen-compatible policy server.  The NuGet package was added to the solution as follows 

<ItemsGroup>
  <PackageReference Include="Rsk.AuthZen.Client" Version="1.0.0"/>
</ItemsGroup>

 

Web Expense Application using a Policy Server for authorization, using the the AuthZen protocol
AuthZen in action

Its very tempting to tightly couple authorization but we recommend creating an abstraction for each area of authorization in your application. This allows the authorization logic to vary, allowing you the flexibility of changing the authorization provider without having to change application code. This is often known as an anti-corruption layer. For this to be effective, the abstraction needs to be independent of any implementation. 

The Razor pages delegate to an authorization service of IAuthorizeExpenseClaimActions. There are three implementations

  • AllowAllAuthorizeExpenseClaimActions
  • AuthZenAuthorizeExpenseClaimActions
  • DenyAllAuthorizeExpenseClaimActions

The AuthZenAuthorizeClaimActions requires the Rock Solid Knowledge NuGet package to perform AuthZen requests to an AuthZen-compatible policy server.  The NuGet package was added to the solution as follows 

<ItemsGroup>
  <PackageReference Include="Rsk.AuthZen.Client" Version="1.0.0"/>
</ItemsGroup>

 

Authorization abstract IAuthorizeExpenseClaimActions and its implementations AllowAllAuthorizeExpenseClaimActions, AuthZenAuthorizeExpenseClaimActions, DenyAllAuthorizeExpenseClaimActions
Authorization abstraction and implementations

Bootstrapping

In WebApp/Program.cs, we configured the AuthZen client and registered our authorization services. TheAuthZenClientOptions points to the policy server we wish to send our AuthZen requests too.  The AuthZen library will use this endpoint to fetch the metadata from the authorizaiton end point, to determine the URLs for the various evaluation endpoints.

The IAuthZenClientis the interface we use to send AuthZen requests, which will be injected into our AuthZenAuthorizeExpenseClaimActionsthat builds and sends the authorization requests to our external policy server using the AuthZen protocol.

builder.Services.Configure<AuthZenClientOptions>(options =>
{
 options.AuthorizationUrl = "https://localhost:7064"; // Our AuthZen policy server
});
builder.Services
       .AddTransient<IAuthZenClient, AuthZenClient>();
builder.Services
       .AddScoped<IAuthorizeExpenseClaimActions, AuthZenAuthorizeExpenseClaimActions>();

 Single Authorization Calls Implementation

The AuthZen protocol supports single- and batch-based authorisations via the evaluation and evaluations endpoints. An AuthZen request is made up of at least the following properties

  • Subject
  • Resource
  • Action

This maps to the typical request of Can Subject perform Action on Resource.  We use a AuthZenSingleRequestBuilderto create the authorizationr request to send to the policy server.

public Task<AuthorizeResult> CanCreateClaim(string submitterUserId)
{
    var requestBuilder = new AuthZenSingleRequestBuilder();
    requestBuilder.SetSubject(submitterUserId, "user");
    requestBuilder.SetAction("CreateClaim");
    requestBuilder.SetResource("newExpense", "expenses");
    var request = requestBuilder.Build();
    return Authorize(request);
}

We used theSetSubject to say who’s doing the action,  theSetAction for what they’re doing, and SetResource for what they’re doing it to. The Authorize method sends the request to the policy server and gives us a result.  If the request is approved, a permit is issued; if not, a denial is issued.

In addition, there may be additional context: the policy we developed on the policy server uses it to return a reason why an authorisation decision was denied.

private async Task<AuthorizeResult> Authorize(AuthZenEvaluationRequest request)
{
    AuthZenResponse response = await client.Evaluate(request);
    bool success = response.Decision == Decision.Permit;

    if (!success)
    {
        string? error = 
            JsonSerializer.Deserialize<JsonElement>(response.Context)
            .GetProperty("error")
            .GetString();
            
        return new AuthorizeResult(false, [error ?? string.Empty]);
    }
    return new AuthorizeResult(success);
}

Some authorization requests require more than Subject, Action and Resource. In AuthZen each of those areas can contain additional properties. For the authorization request for creating a specific expense claim we need to send the amount of the claim. We have chosen to include that as an additional property of the expense resource.

Creating an expense
Creating an expense
public Task<AuthorizeResult> CanSubmitClaim(string submitterUserId, decimal grossCost)
{
    var requestBuilder = new AuthZenSingleRequestBuilder();
    requestBuilder.SetSubject(submitterUserId, "user");
    requestBuilder.SetAction("SubmitClaim");
    requestBuilder.SetResource("newExpense", "expenses").Add("total", grossCost);
    var request = requestBuilder.Build();
    return Authorize(request);
}

Attributes used for authorization

While the AuthZen protocol allows the caller to provide attributes to allow the policy server to determine if to permit/deny the request, policy servers may use a policy information point to obtain additional information required to authorize the request that is not present in the request. In this case, the subject's role is not provided in the AuthZen request, but is obtained by the Policy Server whenever it needs to consider the subject's role to make a decision.

Bulk Authorization Implementation

Sometimes, we need to check whether a user can perform an action on a batch of claims at once (e.g., approving or rejecting several claims). For that, we use AuthZen’s boxcar (bulk) request feature. We build a request for each claim and send them all together. The action proceeds only if all requests are permitted.We use this method for both CanApproveClaims and CanRejectClaims.
 

Approving multiple claims
Multiple approval authorizations
private async Task<AuthorizeResult> AuthorizeClaimSubmissionsAction(
  string approverUserId,
  IEnumerable<IExpenseClaimSubmission> submissions,
  string action)
{
    var boxCarRequestBuilder = new AuthZenBoxcarRequestBuilder();
    foreach (var submission in submissions)
    {
        var rb = boxCarRequestBuilder.AddRequest();
        rb.SetAction(action);
        rb.SetSubject(approverUserId, "user");
        rb.SetResource(submission.SubmissionId, "expenses")
          .Add("approver", submission.ApproverUserId);
    }
    var request = boxCarRequestBuilder.Build();
    var result = await client.Evaluate(request);
    bool success = result.Evaluations.All(e => e.Decision == Decision.Permit);
    return new AuthorizeResult(success);
}

Summary

  • AuthZen offers standards based authorization. Offering AuthZen authorisation in your applications lets you or your customers choose the authorisation service they prefer.
  • Create a strong anti-corruption layer for authorisation to give you the flexibility in choosing authorisation providers
  • Rock Solid Knowledge FOSS NuGet package allows you to add standards-based authorisation to your .NET application today, and allows you to integrate with your AuthZen-compatible policy server of choice.
  •  You can find the source code for this sample and the AuthZen NuGet package here

 

 

Andrew Clymer He/him

Job Role
Managing Director
Company
Rock Solid Knowledge
Andrew is the Managing Director at Rock Solid Knowledge.

Related Articles