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. But what does that actually comprise?
This document explores and illustrates some of OACC's features and compares them with those common in other popular authentication and authorization frameworks. Let's start by taking a look at OACC's authentication API features below.
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 AuthenticationProvider interface.
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.
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, out of the box.
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.
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 (i.e. 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.
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.
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.
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 through 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.
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
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 databases.
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 parititioning 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. As a result, OACC doesn't load a subject's entire permission set into memory up front and then iterate over it for each authorization check.
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.