Authorizing Resources Based On Who Created Them

A colleague of mine pointed out to me an interesting question on StackOverflow. They suggested that it might be a good question for me to answer because of my experience with Spring.

The question was, "how to authorize specific resources based on users who created those in REST, using annotations."

What I'm trying to do is create an annotation named @Authorize and use it on methods that need user authorization to perform some action  (the user is already authenticated at this point). For example, I have an order service with a  getOrder() method. I want only the user who created this order to access it.

My Answer on StackOverflow

To implement authorization controls on methods in Java, I highly recommend using Spring Security with an eXtensible Access Control Markup Language (XACML) implementation that has a Spring Security API.

Spring Security

Spring Security provides two main actions to protect access to methods:

• Preauthorization: this allows for certain conditions/constraints to be checked before the execution of the method is allowed. Failure to verify these conditions will result in the failure to call the method.
• Post-authorization: this allows for certain conditions/constraints to be checked after the method returns. This is used less often than the preauthorization check, but it can be used to provide extra security around complex interconnected business tier methods, especially around constraints related to the object returned by the method.

For example, one of the access control rules is that the user has the ROLE_ADMIN authority before being able to invoke the method  getEvents(). The way to do that within the Spring Security framework would be to use the PreAuthorize annotation as below:

public interface Sample { ... 
@PreAuthorize("hasRole('ROLE_ADMIN')") 
Event getEvent(); } 

In essence, Spring Security uses a runtime Aspect Oriented Programming (AOP) pointcut to execute before an advice on the method and throw an o.s.s.access.AccessDeniedException if the specified security constraints are not met.

More can be found about Spring Security's Method Level Security in section 27.3 of this document.

eXtensible Access Control Markup Language (XACML) 

Spring Security does a great job of implementing access control with its expression-based access control. However, the attribute-based access control (ABAC) allows more fine-grained control of access and is recommended by the National Institute of Standards and Technology.

To address the limitations of Role Based Access Control (RBAC), NIST came up with a new model called ABAC (Attribute Based Access Control). In ABAC, you can now use more metadata/ parameters. For instance, you can consider:

• a user's identity, role, job title, location, department, or date of birth
• a resource's type, location, owner, value, department, etc.
• contextual information, e.g. time of the action that the user is attempting on the resource

All these are called attributes. Attributes are the foundation of ABAC, hence the name. You can assemble these attributes into policies. Policies are a bit like the secret sauce of ABAC. Policies can grant and deny access. For instance:

• An employee can view a record if the employee and the record are in the same region
• Deny access to reading records between 5 pm and 8 am.

Policies can be used to express advanced scenarios. For example:

• segregation of duty
• time-based constraints (see above)
• relationship-based access control (see above)
• delegation rules delegate Bob access to Alice's document.

There are two main syntaxes available to write policies:

• the Abbreviated Language for Authorization (ALFA), which is based on XACML
• the eXtensible Access Control Markup Language (XACML)

ABAC also comes with an architecture to define how the policies will get evaluated and enforced.

The architecture contains the following components:

• The Policy Enforcement Point (PEP): this is the component that secures the API / application you want to protect. The PEP intercepts the flow, analyzes it, and sends an authorization request to the PDP (see below). It then receives a decision (Permit/Deny) that it will enforce.
• The Policy Decision Point (PDP) receives an authorization request (e.g. can Alice view record #123?) and evaluates it against the set of policies it has been configured with. Eventually, it reaches a decision, which it sends back to the PEP. During the evaluation process, the PDP may need additional metadata, e.g. a user's job title. To that effect, it can turn to policy information points (PIP).
• The Policy Information Point (PIP) is the interface between the PDP and underlying data sources, e.g. an LDAP, a database, and a REST service that contains metadata about users, resources, and more. You can use PIPs to retrieve information that the PDP may need at runtime, e.g. a risk score, a record's location, etc.

Implementations of XACML

In full disclosure, I am on the XACML Technical Committee and work for Axiomatics, a provider of dynamic authorization that implements XACML.

Axiomatics provides a Spring Security SDK for their Axiomatics Policy Server and four expressions that can be used to query the PDP as a part of protecting a method invocation

1. xacmlDecisionPreAuthz, called with @PreAuthorize
2. xacmlDecisionPostAuthz, called with @PostAuthorize
3. xacmlDecisionPreFilter, called with @PostFilter
4. xacmlDecisionPostFilter, called with @PreFilter

The exact signatures for these methods are as follows:

1. xacmlDecisionPreAuthz(Collection<String> attributeCats,
Collection<String> attributeTypes, Collection<String> attributeIds,
ArrayList<Object> attributeValues)
2. xacmlDecisionPostAuthz(Collection<String> attributeCats,
Collection<String> attributeTypes, Collection<String> attributeIds,
ArrayList<Object> attributeValues)
3. xacmlDecisionPreFilter(Collection<String> attributeCats, Collection<String>
attributeTypes, Collection<String> attributeIds, ArrayList<Object>
attributeValues)
4. xacmlDecisionPostFilter (Collection<String>
attributeCats, Collection<String> attributeTypes, Collection<String>
attributeIds, ArrayList<Object> attributeValues)

For an entire list of XACML implementations, you can check this list on Wikipedia.