Skip to content
This repository has been archived by the owner. It is now read-only.
Sample OSS version of PolicyServer
C# HTML PowerShell Shell CSS JavaScript
Branch: master
Clone or download

Latest commit

Latest commit 8126b19 Apr 19, 2020

Files

Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
src update description Sep 29, 2019
test/PolicyServerLocal.Tests Update to core 3. Sep 25, 2019
tools rename, add build script Jan 3, 2018
.gitignore rename, add build script Jan 3, 2018
LICENSE add license headers, cleanup Jan 3, 2018
PolicyServer.Local.sln rename, add build script Jan 3, 2018
README.md Update README.md Apr 19, 2020
build.cake update build and csproj Sep 29, 2019
build.ps1 rename, add build script Jan 3, 2018
build.sh rename, add build script Jan 3, 2018
icon.png update build and csproj Sep 29, 2019

README.md

PolicyServer (local version)

We've been talking about separation of concerns of authentication and authorization quite a bit in the past (see the blog post that started all and the video that showed off our first prototype). As a result, we have developed a commercial product called PolicyServer as part of a joint venture with Solliance. Here are a few links to the product and pricing page:

In this repository we have provided a free, open source, and simplified version of the authorization pattern we propose - with the necessary code to create a simple implementation in your applications. This is meant to be a sample, if you find this approach useful, feel free to copy the code and use it in your own projects.

NOTE: This open source library does not have the advanced features of the PolicyServer product like hierarchical policies, client/server separation, management APIs and UI, caching, auditing etc., but the client library is syntax-compatible with its "big brother" in terms of integration to your applications. This allows an upgrade path with minimal code changes if you start with this client library.

Important This code-base was our proof of concept for the client-side programming model. We will leave it here for other people that might find this useful, too. It is not maintained anymore!

Defining an authorization policy

The authorization policy is defined as a JSON document (typically in appsettings.json). In the policy you can define two things

  • application roles (and the users that are members of these roles)
  • application permissions (and which application roles have these permissions)

Defining application roles

Role membership can be defined based on the IDs (aka subject IDs) of the users, e.g.:

{
  "Policy": {
    "roles": [
      {
        "name": "doctor",
        "subjects": [ "1", "2" ]
      }
    ]
  }
}

The value of the user's sub claim is used to determine role membership at runtime.

Additionally identity roles coming from the authentication system can be mapped to application roles, e.g.:

{
  "Policy": {
    "roles": [
      {
        "name": "patient",
        "identityRoles": [ "customer" ]
      }
    ]
  }
}

The user's role claims are used to map identity roles to application roles.

Mapping permissions to application roles

In the permissions element you can define permissions, and which roles they are mapped to:

{
  "Policy": {
    "roles": [
      {
        "name": "doctor",
        "subjects": [ "1", "2" ],
        "identityRoles": [ "surgeon" ]
      },
      {
        "name": "nurse",
        "subjects": [ "11", "12" ],
        "identityRoles": [ "RN" ]
      },
      {
        "name": "patient",
        "identityRoles": [ "customer" ]
      }
    ],
    "permissions": [
      {
        "name": "SeePatients",
        "roles": [ "doctor", "nurse" ]
      },
      {
        "name": "PerformSurgery",
        "roles": [ "doctor" ]
      },
      {
        "name": "PrescribeMedication",
        "roles": [ "doctor", "nurse" ]
      },
      {
        "name": "RequestPainMedication",
        "roles": [ "patient" ]
      }
    ]
  }
}

Using the PolicyServer client library in your ASP.NET Core application

First, you need to register the PolicyServer client with the DI system. This is where you specify the configuration section that holds your policy.

services.AddPolicyServerClient(Configuration.GetSection("Policy"));

After that you can inject the IPolicyServerClient anywhere into your application code, e.g.:

public class HomeController : Controller
{
    private readonly IPolicyServerRuntimeClient _client;

    public HomeController(IPolicyServerRuntimeClient client)
    {
        _client = client;
    }
}

PolicyServerClient has three methods:

  • EvaluateAsync - returns application roles and permissions for a given user.
  • IsInRoleAsync - queries for a specific application role
  • HasPermissionAsync - queries for a specific permission
public async Task<IActionResult> Secure()
{
    // get roles and permission for current user
    var result = await _client.EvaluateAsync(User);
    var roles = result.Roles;
    var permissions = result.Permissions;

    // check for doctor application role
    var isDoctor = await _client.IsInRoleAsync(User, "doctor");
    
    // check for PrescribeMedication permission
    var canPrescribeMedication = await _client.HasPermissionAsync(User, "PrescribeMedication");

    // rest omitted
}

You can now use this simple client library directly, or build higher level abstractions for your applications.

Mapping permissions and application roles to user claims

Instead of using the PolicyServerClient class directly, you might prefer a programming model where the current user's claims are automatically populated with the policy's application roles and permissions. This is mainly useful if you want to use the standard ClaimsPrincipal-based APIs or the [Authorize(Roles = "...")] attribute.

A middleware (registered with UsePolicyServerClaims) is provided for this purpose, and runs on every request to map the user's authorization data into claims:

public void Configure(IApplicationBuilder app)
{
    app.UseAuthentication();
    app.UsePolicyServerClaims();

    app.UseStaticFiles();
    app.UseMvcWithDefaultRoute();
}

Then in the application code you could query application roles or permissions like this:

// get all roles
var roles = User.FindAll("role");

// or
var isDoctor = User.HasClaim("role", "doctor");

Mapping permissions to ASP.NET Core authorization policies

Another option is to automatically map permissions of a user to ASP.NET Core authorization policies. This way you can use the standard ASP.NET Core authorization APIs or the [Authorize("permissionName")] syntax.

To enable that, you need to register a custom authorization policy provider when adding the PolicyServer client library:

services.AddPolicyServerClient(Configuration.GetSection("Policy"))
    .AddAuthorizationPermissionPolicies();

This will allow you to decorate controllers/actions like this:

[Authorize("PerformSurgery")]
public async Task<IActionResult> PerformSurgery()
{
    // omitted
}
You can’t perform that action at this time.