Announcing PolicyServer

Over the course of the last years Brock, Michele and I have all been actively designing and implementing identity solutions for customers of all sizes and industries. Solutions range from simple to complex – and almost always involve both identity (authentication) and access management (authorization).

It turns out that, for authentication there is pretty much always only one right way to do it, once you know all the facts and requirements. Once you are done with the “who is the user” (aka authentication) part, you will inevitably need to solve the “and what is this user allowed to do” (aka authorization) problem next.

So, many people asked us to provide the same turnkey solution for authorization as we do for authentication with IdentityServer.

One very tempting fallacy is that you can use your new and shiny identity system to also distribute authorization data to your applications. This will not work! Despite what some vendors try to tell you when selling their “Identity and Access Management” solution. Identity is universal – authorization is application specific. Blurring those lines will get you in trouble. Back in 2016 I wrote a pretty popular blog post about that – and last year Brock and I did a talk about our ideas at NDC. I don’t want to repeat all that again here.

Since we never really had a good answer, we decided to dedicate some time to think about the problem. We started by observing how our customers implemented their authorization in the past. The results were quite interesting – from highly specialized application logic to “standard” concepts like access control lists (ACLs) or (the failed) XACML, we found that the most prevalent general concept that people use is roles and permissions.

While this doesn’t sound like rocket science – almost no-one took the time to build a general solution for that. They rather re-implemented one or the other aspect of this pattern over and over again for each application they were building.

This was our starting point for what we now call PolicyServer (watch the above NDC video to see an early prototype). We had the following key tenets in mind.

Built from the ground-up for modern applications

With that we mean the modern multi-client, multi-platform, API-driven systems that companies implement today. It must be compatible with all current prevalent architecture styles like cloud, microservices, multi-tenancy (you name it) and of course, uses claims-based identity at its core.

Identity != Permissions

There will be a strict separation of authentication and authorization. This way you can keep your architecture clean and ready for growth. Everything else will become a problem when your software becomes more complex than initially planned.

Identity + Permissions == Authorization

Identity will be the input to the authorization system. A user will most likely have different permissions in different applications – the combination of identity and context produces the actual authorization policy.

Enter PolicyServer

So simply said – PolicyServer allows you to model applications roles, membership and permissions for your applications. But of course, there is much more to it.

Policy design

We want to be able to model arbitrary applications styles – from simple, single applications to application systems and multi-tenanted applications. In PolicyServer, policies are containers for application roles and their associated permissions, but policies can be hierarchical and support inheritance.

Role membership

Membership to application roles can be defined statically (and drawn from the separate identity system) or based on rules and claims-transformation.

Permissions

Permissions belong to application roles. In your applications, you can use the application roles for coarse grained authorization, and permissions for fine-grained authorization.

Management API and UI

Every management aspect of PolicyServer is API first. There is a full-featured web-based UI for managing policies – but you can also automate everything, or drive policy creation and permission management from your own application.

Auditing and compliance

Permission usage and policy evaluation can be fully audited and the resulting audit trail can be tailored to meet common compliance criteria.

Client libraries

So far we have focused mainly on .NET – this includes a base client library, but also support and deep integration into the new ASP.NET Core policy-based authorization system. This has also been back-ported to MVC5/Web API 2. In the future we will support more common application platforms – but given the API nature of our runtime engine, integration is trivial.

 

The three of us all have implemented authorization products and solutions for customers in the past, and so PolicyServer is the result of us collaborating – as we all shared a passion for the problem space.

While implementing more and more pieces, it became pretty clear, that this is a lot of work. Given our engagement with our existing open source projects like IdentityServer and IdentityModel, we couldn’t afford to start another OSS project. That’s why we decided to create two versions of PolicyServer.

One version is a free OSS version that includes all the necessary bits and pieces to implement the separation of concerns between authentication and authorization. But it will be for a single application only and not include the management pieces or the advanced modeling capabilities.

The other version is a commercial product that has all the above-mentioned features –  and if you think that would be a good fit for your application – let’s have a chat!

This entry was posted in PolicyServer. Bookmark the permalink.

17 Responses to Announcing PolicyServer

  1. Mark says:

    Great to see some good work in this space.
    I maybe involved with a planned future microservice application in Azure AKS (when it’s GA) so may need the commercial product for its multi application support.
    I was wondering if the commercial product is offered containerized so it can be run in container orchestrators like a kubernetes cluster? If the installation/setup is complex perhaps even a helm chart to simplify the deployment?

  2. Mark,

    yes – absolutely.

  3. Brian says:

    I’m very excited to try this out! Thank you, as always.

  4. Stephen says:

    Might just be me, but the NDC talk link seems broken today? It was working a couple of days ago. I think there’s a youtube link as well FWIW. https://www.youtube.com/watch?v=EJeZ3YNnqz8

  5. GB says:

    How do you see this working with oauth scopes? Typically you should get a different answer whether a user is allowed to do something or not if the client requested certain scopes. How does that tie into PolicyServer?

    • Scopes are about client authorization. PolicyServer is about user authorization.

      • GB says:

        When a user consents to some specific subset of actions, shouldn’t then the PolicyServer permission check return a different result on whether that action is allowed or not? Or do you see that as another layer somehow? I understand it in theory, I’m just not sure how to architect it.

  6. No. Because PolicyServer is about what the user is allowed to do – not the client.

  7. Jenan says:

    The commercial version of PolicyServer include managing of policies for more applications or is it required for every single application run separate PolicyServer Admin UI? I can see in the latest presentation from NDC conf, that you had the PolicyServer but probable only for one application. Thank you.

  8. aaronralls74 says:

    Is there a way to have the policyserver as an API resource under IdentityServer4 and for IdentityServer4 to be a client that is authorized to use it as well?

  9. Konrad says:

    How is that different than using ASP.NET Core Identity with roles for example?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s