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.

Published by Michael

I started my website in 2017 to help people learn more about information technology in order to help them become more successful in their careers. I earned my bachelor's degree from New York University, have been working in cyber security since 2012, and live in the Washington D.C. Metro area. I have found running a blog to be one of the greatest assets in helping my career and have found it could even bring in a few extra bucks each month. Starting a blog is easy and rewarding. To keep my knowledge current, I take courses on Udemy and Treehouse. By using my links, you can get a discount on both.

Join the Conversation

5 Comments

  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 comment

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

%d bloggers like this: