1. Overview
Today, we’ll be reviewing the differences between Expression-Based Access Control (EBAC), Role Based Access Control (RBAC), and Attribute Based Access Control (ABAC), with a deeper focus on EBAC.
2. What is Expression-Based Access Control?
Simply put, Expression-Based Access Control is the use of expressions to write authorization.
The phrase Expression-Based Access Control (EBAC) is currently most commonly associated with the use of the Spring Expression Language expressions to write authorization.
It was in Spring Security 3.0 that the ability to use Spring EL expressions as an authorization mechanism in addition to the simple use of configuration attributes and access-decision voters was introduced.
However, using expressions for access control is NOT limited to just Spring Security! This blog post is partially a request to the greater community to recognize the use of expressions in authorization as Expression-Based Access Control (EBAC), since it is uniquely different than other forms of access control, due to its ability to let you implement other forms of access control such as RBAC and ABAC.
Other examples of EBAC include the Access Control Expressions (ACE) in MapR and Dynamic Access Control in Windows. There may others as well, such as the PHP Framework Symfony.
Is Expression-Based Access Control (EBAC) Equivalent to Attribute Based Access Control (ABAC)?
No, but ABAC can be implemented with EBAC.
Here is a high level definition of ABAC according to NIST Special Publication 800-162:
An access control method where subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions
With this in mind, we could write our own using an expression language, such as Spring Expression Language based expressions, that can then call with the existing @PreAuthorize, @PostAuthorize, @PreFilter and @PostFiler, sec:authorize tags and even from intercept-url conditions.
Is Expression-Based Access Control (EBAC) Equivalent Role Based Access Control (RBAC)?
No, EBAC is not equivalent to RBAC, but RBAC comes built-in to certain expression languages such as Spring EL. For instance, there are these two common expressions that allow us to implement RBAC with ease:
- hasRole([role])
- hasAnyRole([role1,role2])
However, when writing fine-grained authorization rules, we easily begin to write expressions that surpass the granularity level of RBAC.
3. Web Security Expressions
EBAC implementations, such as Spring Security, allow us to secure URLs. The expressions should evaluate to true or false, defining whether or not access is granted. An example of restricting access in a RESTful application base on userID in a Java configuration:
http
.authorizeRequests()
.antMatchers("/user/{userId}/**").access("@webSecurity.checkUserId(authentication,#userId)")
...4. Method Security Expressions
Method security is more complicated than permit or deny.
For example, in Spring Security, there are four annotations that take expression attributes to perform pre and post-invocation authorization checks and also to support filtering of submitted collection arguments or return values.
@PreAuthorize, which is the most commonly used, decides whether a method can actually be invoked or not.
@PostAuthorize, an uncommonly used annotation, performs an access-control check after the method has been invoked.
With @PostFilter, Spring Security iterates through the returned collection and removes any items for which the provided expression is false.
@PreFilter allows us to filter before the method call, but this is less commonly used.
Below we have an example of combining PreAuthorize with @PostFilter for more fine-grained security:
@PreAuthorize("hasRole('USER')")
@PostFilter("hasPermission(filterObject, 'read') or hasPermission(filterObject, 'admin')")
public List<contact> getAll();5. When to Use Expression-Based Access Control (EBAC)?
If the security we need requires more granularity than simple Access Control Lists (ACLs), then we need to use EBAC. How we decide to implement EBAC is a matter what resources we have available to us. For instance, in an organization that uses Spring Security, then why not use their Spring EL? Likewise, if we have MapR, then we’d use their Access Control Expressions.
In other situations, in order to meet the needs of the organization, it may be required to write our own expression language in the favored language in order to implement EBAC. The reason why we’d spend time doing this, of course, is to allow us to implement whatever kind of access control we want, with the conditions we want. Once we have the adequate expression language to accomplish this, another benefit is that we are less likely to rely on others – whether commercial off the shelf products or open source.
6. Conclusion
Various software comes with the ability to write authorization using expressions, such as MapR, Windows, and, of course, Spring Security. If fine-grained access control can be accomplished using the expressions, I refer to it – and suggest you refer to it – as Expression-Based Access Control (EBAC). By giving it a name, we are more likely to use it to secure our systems over traditional RBAC. This is good because fine-grained access control, when done properly, is more likely to prevent breaches.
| Published on Java Code Geeks with permission by Michael Good, partner at our JCG program. See the original article here: Expression-Based Access Control Opinions expressed by Java Code Geeks contributors are their own. |
