How to authorize specific resources based on users who created those in REST, using annotations

Question

I do not understand Java annotations with retention policy as RUNTIME that well. 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. `

public void getOrder(User user) {
   //current code does something like this
   if(order.getCreatedBy().equals(user)) {
     //then proceed. 
}

} `

I do not want to mix this logic with business logic. Instead, I'm looking to have something like this- `

@Authorize
public void getOrder(User user) {
   //business logic
}

` There are several methods but not all of them would need such authorization. Could someone please explain me how can I fit the pieces together here? What I don't understand at this point is that how AnnotationProcessor would help me here since it does its magic at compile time. As far as I understand, it will help me generate some code at compile time but I have no clue how to use that generated code. I went through numerous examples on AnnotationProcessors but I'm still missing something. These links helped me a bit to understand annotation processing so far-

http://hannesdorfmann.com/annotation-processing/annotationprocessing101 https://equaleyes.com/blog/2017/09/04/annotation-processing/

Even if I go with reflections, where should I place the reflection logic? and is it counter productive of what I'm trying to achieve?

At this point, I'm open to other solutions as well which do not involve annotations but will help me separating out business logic with such resource specific authorization.

Answer 1

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:

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