Claim based access control in a distributed system

Question

I'm trying to get my head around using Claims based access control in a distributed system and how and where to manage these. I also think I'm getting confused over claims issued by an authentication service and claims issued by an authorisation service, so I'd be grateful for any advice helping me clear this up.

Scenario

I have a trusted federation server that is used for single-sign-on for a number of microsites. Each microsite has a specific purpose. E.g. a Product Portal (used for the creation and management of products) and a Billing Portal (used for the creation, viewing and payment of invoices).

The system is used by many people: Administrators that have full reign over the whole system. The internal finance department is only concerned with the billing portal. Likewise the internal product team is only interested in the product portal. And finally a customer, that needs to access both portals but without any backend permissions.

Federated authentication

As I understand it, when the user successfully authenticates with the federation server, the federation server provides the requesting microsite with claims about that user's identity. Such claims might include :

• The user email address : [email protected]
• The user name : Bob
• The user type : Product team
• Anything else that relates to the users identity

It does not provide anything that relates to what the person can do (this might be my first misconception). Note that the user type is effectively a claim to a role. Is this terminology correct ? Is a claim in this context different to a permission claim ?

Microsite authorisation

Once the user is authenticated, the microsite needs to know what that user is allowed to do. Whilst the site is handed a user type (which is a claim to a roll), I would prefer to use a claims based approach. This would give finer granularity on permissions. E.g :

• Bob should be able to edit prices but not create products.
• Bill (also in the products team) should only be able to add products.
• Ben should only be allowed to delete products.
• Alice (finance) should have no permissions.

Using claims, as apposed to rolls gives the microsites extra flexibility to grant specific permissions.

The question(s)

• Where should these claims to allowed actions be stored ?
• Should each microsite provide it's own federation identity -to- microsite claim mapping service ?
• Should each microsite cache these claims ? What if Bob moves from the Products team to the Finance team ?

The reason I'm asking is because we've had a debate in our development department and our most senior developer is of the opinion that the federation server should provide all the claims that each microsite needs. This seems to me like it would tightly couple the federation service to each microsite.

Answer 1

So... there are several pieces at work here. Let's get to work.

First, a Central Authentication Service is a great way to authenticate Users in a distributed system scenario, but might not be the best place to handle authorization for all its connected microsites and/or microservices.

Claims-based authentication

To make it clear, in the CAS (Central Authentication Service) is where you add all relevant claims, be them roles, flags, and any other information you might need later on.

But here is where I would advice you to get familiar with Resource based authorization too (if you haven't already).

Resource-based authorization

The concept here is to determine access to parts of your systems (microsites/microservices) and to specific functionality by asking the Claims Principal whether the User has access to a Resource instead of a Role.

Now, here is where people usually get lost in translation. Roles are represented as Claims; Resources are also represented as Claims.

To figure out access to the Product Portal, you can check whether the ProductPortal Claim exists (could be named whatever). The important part is that you're not checking whether the User has an Admin Role or not, but rather checking against the precense of a Resource Claim. So, when you decide down the road that not only Users with an Admin Role should access the portal, you could add the ProductPortal Resource Claim to any other users you which to bestowed it upon based on any criteria you need, e.g.: Roles, Flags, et. al.

But, this represents a problem down the road. If you add a claim for every resource you'll need in every microsite/microservice in your distributed system, you'll end up with a huge load of claims. Not only that, but since some resources would be relevant on some microsite/microservice yet not in others, you're carrying around a loaded bag where only a handful of claims are relevant to a given microsite/microservice at any given time.

Fret not however, as there is an elegant solution for that too.

Claims Transformation

This is a process which you would usually register as a middleware or filter to intercept every request, read the claims (and hence its roles and flags) and enrich the incoming Claims Principal with the Resource claims relevant for the microsite/microservice you're entering.

This way, you're not carrying a huge bag of claims around, and on top of that you get to decouple Authentication from Authorization, pushing the logic that translates normal claims into Resource claims to the system that knows best about the Resources it would need to control access and permissions for sections and functionalities down to a granular level if you wish it so.

---

To the point

• Where should these claims to allowed actions be stored ?

In the Claims Principal, which you can be passing around as an Access Token, a Session Variable or what not

• Should each microsite provide it's own federation identity -to- microsite claim mapping service?

The Claims Transformation (or Claims Mapping) would reside in each microsite; the place that knows the most about the Resources that would map its functionality surface best.

• Should each microsite cache these claims ? What if Bob moves from the Products team to the Finance team ?

No, no caching. The Access Token (or session) you pass around would hold the bare minimums in the form of claims. Since the enrichment of claims happens in the Claims Transformation process in the microsite, the moment Bob moves from Products team to the Finance team, he would lose some Role Claims and get others, which would properly be translated to the Resource Claims relevant for the Finance microsite at the time of accessing it and give him the access he needs to the sections and functionality you deem appropriate.

---

Hope I didn't make it too confusing.