A commonly asked question about the open-source OACC security framework for Java is how it compares to <insert your favorite framework here>? I always wish I could provide a satisfactory answer as short as that question. The TL;DR seems to be:
OACC solves the same problem, but with a comprehensive security model that is different.
This article explores and illustrates that difference by comparing some of OACC's features with those common in other popular authentication and authorization frameworks. Let's start by defining the general scope of such frameworks for our discussion.
What Problem are Security Frameworks Trying to Solve?
Spring Security, PicketLink, Apache Shiro and OACC are all open-source Java frameworks released under the Apache 2.0 license and provide functionality to make it easier for a Java application to authenticate subjects and check authorization to resources.
- Spring Security's strengths lie in securing web requests and method invocations in an aspect-oriented manner that fits into the greater Spring context
- PicketLink secures JavaEE applications within JEE6+ containers (JBoss/WildFly and others) and features multi-tenancy support
- Apache Shiro emphasizes a consistent and easy-to-use API that fronts application-specific authentication and authorization implementations. In addition, Apache Shiro also provides session management and common cryptographic functionality
- OACC focuses on providing a fully featured API to both enforce and manage an application's authentication and authorization needs - it is a full implementation of a powerful and flexible security model
Let's take a look at OACC's authentication API to see how it compares to those of other popular Java security frameworks below.
What are the Similarities and Differences in Terms of Authentication?
Pluggable Authentication Protocols
All the popular Java security frameworks support pluggable authentication protocols, as does OACC. Both Spring Security and Apache Shiro, for example, come with several popular authentication protocol implementations, such as LDAP, Active Directory, OAuth, etc. OACC, on the other hand, currently only ships with a production-ready secure password-credentials implementation, to get you started. Alternatively, you can use any authentication protocol your application requires by implementing the simple
(Note: we welcome any contributions of other authentication protocol implementations - OACC is on Github if you'd like to share yours!)
OACC provides identity delegation by letting an authenticated subject "impersonate" another subject. This feature is essential in scenarios where a customer service representative or admin needs to act on behalf of regular customers or users, without having to know their authentication credentials. The equivalent can be achieved in Apache Shiro with the
runAs()method, or in Spring Security with the somewhat obscure
RunAsManager The difference in OACC is that delegation itself is a controlled operation: the authenticated subject needs to be authorized to assume the other's identity by having the
*IMPERSONATE permission on the other subject.
Next, let's look at OACC's authorization API features to explore OACC in more detail.
What's Different About Authorization in OACC?
Complete Framework With a Rich API
OACC features a fully functioning, rich API that doesn't require any DIY implementation to enable the programmatic and dynamic modeling of complex security scenarios. In other words, OACC provides all the functionality to manage your application's security model, right out of the box.
Fully Implemented Data Store
OACC supplies a fully implemented RDBMS-backed data store for its security model, which the API manages for you behind the scenes. All you have to do is run the provided SQL setup scripts for the database of your choice (OACC supports DB2, SQL Server, Oracle, PostgreSQL, HSQLDB, MySQL / MariaDB, and SQLite), and configure a data source. No custom SQL or DAO implementation is required, and you won't pollute your application's data model with security-related information.
Permission-based Security Model
OACC's security model is permission-based: it essentially manages permissions between resources.
Resources represent both secured objects and the actors on them (i.e. subjects). Combined with other key abstractions (resource classes, domains, and global permissions), this allows for the modeling of many flexible and scalable security scenarios, some of which are featured in more detail in the remainder of this article.
Permissions can represent any operation you need to secure, and because they are String-based, there is no limit to the number of defined permissions per resource class. There is also no need for "voters" or decision algorithms to be configured, since the concept of negative permissions (e.g. "deny read") isn't supported. A resource either "has" a permission to another, or it doesn't.
Single Access Control Paradigm
Other frameworks allow role membership or expression-language checks to enforce some level of authorization at the web and service layers (URLs and methods), and then provide a separate ACL interface to secure the domain model layer (objects).
OACC, on the other hand, avoids such a patchwork of access control paradigms by operating solely at the resource-level, which naturally lends itself to securing instances at the domain model layer, and is flexible enough to cover the web or service layer. For most operations, access control ultimately boils down to answering the question:
Does resource A have permission to perform action P on resource B?
In other words, one can usually express web- or service-level authorization as permissions on resources.
Annotations or Expression Language Support
OACC is a security framework that facilitates programmatic authorization at the code-level, thus there currently is no support for aspect-oriented intercepts with annotations or expression language constructs. Instead, simple API methods to check or assert permissions allow for authorization enforcement.
True RBAC Modeling
If role membership checks aren't enough to secure your application, you'll be pleased to learn that OACC supports full RBAC, in which a "role is essentially a collection of permissions"(NIST). Roles - and groups for that matter - can be modeled via permission inheritance, allowing for hierarchical roles through which a subject transitively acquires any assigned permissions. Every authorization check thus takes the form of:
Does resource A have permission P on resource B? and will be evaluated dynamically.
Symmetric Query Methods
OACC provides efficient query methods to find resources by permission, without loading all resources first and then filtering out the unauthorized ones. These methods are symmetric in the sense that you can find both
- the resources to which a specified resource has a specific set of permissions, and
- the resources that have a specific set of permissions to a specified resource
For auditing or for purposes of managing authorization, these query methods make it easy to find, for example, users "belonging" to a role or users that have permissions on a resource.
OACC is the only framework that natively supports delegation control at the authorization level. With OACC, subjects can delegate their permissions to others. This can be dynamically controlled by assigning or revoking grant options on permissions, similar to the
WITH GRANT OPTION privilege in database systems.
Automatic Permission Assignment
Another novel feature of OACC are create-permissions, which not only control what kind of resources a subject may create, but also define exactly what permissions they would get on a new resource after creating it - defined once, permissions are automatically assigned to a resource creator, without the need for explicit API calls.
OACC supports partitioning the resource space into (hierarchical) logical security domains, which facilitates modeling security scenarios in multi-tenant applications. These domains constitute a useful abstraction in itself because they also allow permissions to be efficiently assigned and queried at the domain-level.
OACC does not yet come with a built-in caching mechanism. To prevent any performance degradation in terms of memory or query time as the size of your secured data set increases, OACC uses dynamic, highly targeted queries into a very efficient data model for all access control checks. In other words, OACC doesn't load a subject's entire permission set into memory up front and then iterate over it for each authorization check.
A Different Solution to the Same Problem
As you can see, the exploration of OACC's features above is extensive and probably not exhaustive. You now understand that OACC is not "just another" security framework, but that it approaches the common problem of authorization within your application in a unique way:
OACC is a comprehensive and fully implemented API that flexibly and scalably secures your resources with a single access control paradigm.
If you are looking for an open-source security framework for Java that provides authentication and advanced authorization services, I invite you to give OACC a try or to find more information - including the latest Javadocs, releases, and tutorials - at oaccframework.org.