Authorization checks without littering them in code

Question

My team is currently trying to design an authorization system that can be used in any language (Think authorization as a service). One thing i'm trying to figure out is if there is a good way to write authorization checks without littering them all over my code.

Is there any way to actual do this in practice?

For example I'd like to NOT have statements like this all over my code:

if(user.authorizedTo("create")) {
  // Show button or something
} else {
  // Don't show button
}

Clarification on a couple simple use cases. I want a system that can at a minimum handle both of these:

• Decide whether to show a component in a UI
• Decide whether to allow a method to be executed in backend code

Answer 1

What you are asking for has a name, a model, and even implementations (open-source libraries as well as commercial products).

Externalized Authorization Management

What you are looking for is called Externalized Authorization Management (Gartner) sometimes also called Dynamic Authorization Management (Kuppinger Cole). EAM lives within the Identity & Access Management (IAM) space which itself lives within the IT security realm. Here's a slide I often use in EAM training.

The whole idea behind is externalized authorization is that:

• You get to define authorization logic outside the application
• You get to manage authorization logic via a central component (centralized authorization)
• Authorization logic is expressed as policies rather than code: this is called policy-based access control
• Policies use attributes to determine what is allowed and what is not allowed. This is called Attribute Based Access Control.
• Authorization is defined in a technology-neutral way which means the same authorization policies can be reused across multiple layers in a consistent and coherent way. This enables defense-in-depth and policy reuse. Decision making is done centrally whereas enforcement is done locally in the layer where it matters (API, database, network...)

What are the benefits?

• it's easier and faster to write new apps. Much like you do not implement authentication or logging by hand, you no longer need to implement authorization by hand
• it's easier to maintain and update. You can change your authorization policies independently of your code
• it's easier to reuse authorization logic: you no longer need to implement security checks in different technologies and different layers. You eliminate the authorization silos
• it's easier to run audits: audits of what happened (you now have an audit trail) and audits of what could happen. It's easier to give your compliance manager the policies that drive the authorization.

Attribute Based Access Control (ABAC)

There is a formal model behind externalized authorization and it's called ABAC. NIST has defined the approach in their 2013 Guide to Attribute Based Access Control (ABAC) Definition and Considerations.

The whole idea with ABAC is that you express authorization in terms of policies that bring together attributes. Attributes are key-value pairs e.g. role="manager". In ABAC you can define attributes about users, resources, actions, contextual information, and much more. I like to sum it up as who, what, where, when, why, and how... The policies then combine those attributes in pseudo-english statements e.g.

• English: A doctor can view the medical record of a patient in their unit.
• ABAC version: A user with the role == "doctor" can do the action=="view" on an object of type=="medical record" if doctor.unit == patient.unit

ABAC also defines an architecture and an authorization flow:

• the Policy Enforcement Point (PEP) is the interceptor which protects your application
• the Policy Decision Point (PDP) is the authorization engines which decides whether access should be granted
• the Policy Information Point (PIP) is the place where metadata is stored e.g. an LDAP or an application database. If we need to know the patient's assigned doctor, this is where we read it.
• the Policy Administration Point (PAP) is the interface through which policies are centrally managed.

You can read more on ABAC on Stack Overflow and Wikipedia where I regularly update the page.

eXternalized Access Control Management (XACML)

To implement ABAC the model, you need a standard. That standard today is XACML. It's SAML's sibling in a way. Where SAML focuses on authentication and federation, XACML focuses on authorization. Both are standards that belong to the OASIS family of standards and both were started in 2001. XACML is now in its third version.

XACML inherits ABAC's architecture (see above) with the same components. It also defines a way to query for authorization. A request is also made up of attributes. For instance:

• Can Alice view medical record #1?
• Can the user with ID="Alice" do the action="view" on object of type="medical record" with objectId="1"?

The answer is one of four possible decisions: Permit, Deny, NotApplicable, or Indeterminate. Along with the decision, you can also return statements that enrich the flow. For instance, deny + obligation to notify the user's manager about the denied access.

I've added a lot of resources on XACML on Stackoverflow as well as Wikipedia.

Getting started

There are a few ways you could get your hands dirty. First of all, there is free plugin to author XACML policies which you can download here. Secondly, there are a few open source libraries e.g. Balana or SunXACML. There is also an Amazon AWS image that contains a full authorization server which you can spin up.

I hope this helps, David.

Answer 2

I probably don't have enough experience for cover everything but here is a start of answer :

UI : define custom components that handle the rights checks by themselves so you will be able to burry the if/else within the component and write it only once. If you know angularJS (and probably some other Web framework) that would even be native in the templates :

<button ng-show="hasRight(user, "edit") ng-disabled=hasXXXRightOnThisObject(user, object) />

Note that I distinct show and disable in my case :

• if the button is hidden you don't have the right at all for all objects
• if the button is disable some business rule forbidden the operation for this object.

Backend : you could use system providen by frameworks :

• Annotation, either using one providen or your own.
• Configuration using AOP.

Basically : look the library/framework you're using, they're probably tons of way of doing it, just choose carefully and integrate properly with your authentication system. Rights management is something done again and again since the beginning of softwares.