Home » Java » Enterprise Java » Authorizing Resources Based On Who Created Them

About Michael Good

Michael Good
Michael is a software engineer located in the Washington DC area that is interested in Java, cyber security, and open source technologies. Follow his personal blog to read more from Michael.

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.

XACML

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 @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.

Published on Java Code Geeks with permission by Michael Good, partner at our JCG program. See the original article here: Authorizing Resources Based On Who Created Them

Opinions expressed by Java Code Geeks contributors are their own.

(0 rating, 0 votes)
You need to be a registered member to rate this.
Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments