Authorizing Resources Based On Who Created Them

A colleague of mine pointed me to an interesting question on StackOverflow and suggested it may be a good one 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.”

The gist of it is this:

What I’m trying to do is create an annotation named @Authorize and use it on methods which needs user authorization in order to perform some action( the user is already authenticated at this point). eg. 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 Spring Security with an eXtensible Access Control Markup Language (XACML) implementation that has a Spring Security API.

Spring Security

Spring Security provides two main means 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.
  • Postauthorization: this allows for certain conditions/constraints to be checked after the method returns. This is used less often that preauthorization check, but can be used to provide extra security around complex interconnected business tier methods, especially around constraints related to the object returned by the method.

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

public interface Sample { ... 
@PostAuthorize("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 security constraints specified are not met.

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

eXtensible Access Control Markup Language (XACML) – a policy language for ABAC

Spring Security does a great job of implementing access control with its expression based access control, but 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. You can for instance consider:

  • a user’s identity, role, job title, location, department, date of birth…
  • a resource’s type, location, owner, value, department…
  • contextual information e.g. time of day the action 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 5pm and 8am.

Policies can be used to express advanced scenarios e.g.

  • 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 2 main syntaxes available to write policies:

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

ABAC GRAPH

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 send an authorization request to the PDP (see below). It then receives a decision (Permit/Deny) which it enforces.
  • 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. It eventually 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, a REST service which contain metadata about users, resources, or other. You can use PIPs to retrieve information the PDP may need at runtime e.g. a risk score, a record’s location, or other.

Implementations of XACML

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 it provides 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 @PreFilter
  4. xacmlDecisionPostFilter, called with @PostFilter

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.

2 thoughts on “Authorizing Resources Based On Who Created Them”

  1. Nice summary, Michael! Any guidance on when to use ALFA vs. straight XACML?

    BTW… I noticed a potential typo. In the section on “Implementations of XACML,” I’m assuming you meant to say:

    3. xacmlDecisionPreFilter, called with @PreFilter
    4. xacmlDecisionPostFilter, called with @PostFilter

    Right?

    1. Thanks, Steve!

      Deciding on when to use ALFA or XACML depends on your preference of programming language. Due to its ease of use and similarity to third and fourth generation programming languages like Java and C#, ALFA is often the preferred policy authorizing mechanism for many of Axiomatics’ customers.

      However, if you prefer XML, you may prefer working with XACML.

      And, yes, you are right about the typo! Thanks for catching that!

Leave a Reply

Your email address will not be published. Required fields are marked *