FAQs About OACC

You can download the database setup scripts corresponding to the latest OACC libraries from the Get OACC page or get them directly from the OACC-DB repository on GitHub.

Depending on which database you're working with, some of OACC's database setup scripts don't actually do anything and are only provided for completeness' sake, to keep the instruction steps provided in the Getting Started tutorial the same across all database systems.

The reason for a script being commented out varies for each database, but most often results from a database feature that is either not supported and/or is sufficiently handled implicitly. You can find the detailed reason for a commented out script in the "Setup Notes" section of the aforementioned Getting Started tutorial.

Unfortunately the SQL dialects of different database systems aren't all standard compliant and/or portable, so there is some effort involved in adapting OACC's SQL queries to the dialect of each particular database vendor. So far, we feel we have good coverage of supporting the most popular RDBMS out there, but if you think we're missing one in particular, please let us know!

The OACC API has been tested against the specified database systems and versions that the repository folders of the supported database setup scripts are named after. Often you can run OACC on other (especially higher) versions of the same database, as well, without any issues. Though please keep in mind that we didn't actually verify this for all instances.

Running a database setup script against a completely different database system might be possible between certain databases, but similarly to different SQL dialects, there could be small differences in DDL syntax that would cause an issue. Also note that while the database setup scripts might run on a different database system, the SQL queries used by the OACC API might not. It is best to run the OACC test suite against any non-supported database systems before integrating OACC into your application.

Consider the SQLProfile a configuration parameter that tells OACC both what database system it's on (so that it can use a compatible SQL dialect) and which query strategy to employ when traversing the security topology.

The SQLProfile class defines constants for all supported SQL dialects, along with any supported query strategies. You simply pass it as a parameter when getting an AccessControlContext from the SQLAccessControlContextFactory via getAccessControlContext().

First of all, not every database system supports the recursive query strategy because of lack of or limitations regarding Common Table Expressions (CTEs). As a rule of thumb, the recursive query strategy is expected to perform better because it can avoid making multiple database calls to fetch the required data. This is of greater importance the more levels of inheritance your security model employs.

Your actual experience may differ depending on the structure of your security model or the queries you're running; flatter security models might not experience a difference between the two query strategies; similarly the amount of data could also influence the performance between the two strategies. Because they only affect querying without impacting the way the data is stored, you are free to switch between the two strategies if you want to test for a performance difference.

We have informally and implicitly benchmarked the supported database systems as a side effect of running our test suite against them. At this time, the licenses of several of the supported database systems (Oracle, SQLServer, DB2) prohibit publishing any results of benchmarking against other databases.

A resource simply represents an application domain object you wish to secure with OACC.

In OACC's security model, resources are the surrogates that stand in for your application entities and domain objects and take part in authorization relationships.

This essentially means that resources can have permissions on other resources, and OACC can manage and enforce those permissions for you.

The different types of application domain objects you wish to secure in OACC translate into OACC resource classes.

Every resource belongs to exactly one resource class. A resource class is identified by its unique string name (e.g. "DOCUMENT"). Additionally, a resource class has the following properties:

• authenticatable - indicates if resources of this class may authenticate
• unauthenticatedCreateAllowed - indicates if it is permissible to create resources of this class from an unauthenticated context

The sytem resource is OACC's "super user", which is needed in order to define parts of your application model, such as resource classes and available permissions. Registering your application model with OACC is typically a one-time initialization operation, and you wouldn't (read: shouldn't) use the system resource for any dynamic authentication or authorization operations within your application.

The OACC system resource always has zero (0) as its resourceId. Please note that if you're using MySQL/MariaDB or another RDBMS that by default generates the next sequence value when INSERTing 0 (zero) into an auto-incrementing/identity column, you will have to turn that behavior off when performing the OACC system initialization, because OACC attempts to create Ids of value zero for its system objects.
See the Getting Started tutorial for more detail on how to address this issue.

OACC's security model is permission-based: it essentially manages permissions between resources.

A permission can represent any operation you need to secure - OACC itself doesn't attach any meaning to it. You can define the types of permissions available for each resource class, and because permissions are String-based, there is no limit to the number of permissions defined per resource class.

Note that OACC already provides functionality to deal with the life-cycle of resources, so you typically do not have to define *CREATE or *DELETE permissions for any resource class. These built-in permissions are referred to as system permissions and their names exclusively start with an asterisk (*).

Other system permissions that are automatically available to all resource classes are:

• *INHERIT - to inherit all permissions from another resource
• *QUERY - to inquire about (e.g. retrieve or verify permissions) another resource
• *IMPERSONATE - to act on behalf of another authenticatable resource
• *RESET-CREDENTIALS - to reset the authentication credentials of an authenticatable resource

Below are the available system permissions for any domain:

• *SUPER-USER - a resource with this permission on a domain is a super user of that domain and has all permissions on any resource of that domain or its sub-domains, regardless of resource class
• *CREATE-CHILD-DOMAIN - a resource with this permission on a domain is allowed to create a sub domain
• *DELETE - a resource with this permission on a domain is allowed to delete the domain (once it has been cleared of any resources).

A *CREATE permission is a built-in system permission that can be associated between a resource and a resource class, to indicate that the resource is allowed to create resources of that class (similar to the *CREATE-CHILD-DOMAIN permission on domains).

In addition, you can specify what default permissions the creator should get on the created resource; those specified default permissions are also referred to as "create permissions".

A global permission is a permission on a resource class + domain tupel, instead of between a resource and another resource (or domain). If a resource has a global permission, it effectively has that permission on all resources of that resource class in that domain (and in any of its sub-domains).

Yes! OACC is the only framework that natively supports permission 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.

Every resource in OACC exists inside a domain. Domains serve to scope groups of resources, and most security operations in OACC work within the context of a specified domain.

Domains are incredibly useful to isolate groups of resources in multi-tenant applications, but also constitute a useful abstraction in itself, because they allow permissions to be efficiently assigned and queried at the domain-level.

Domains are incredibly useful to isolate groups of resources in multi-tenant applications, but even if your application is not multi-tenant, we recommend you create at least one domain specific to your application.

Domains are a powerful abstraction in your security model in general, because they allow permissions to be efficiently assigned and queried at the domain-level.

Most popular Java security frameworks support pluggable authentication protocols, as does OACC. An authentication provider is the pluggable part that provides the mechanism to authenticate a resource based on specified credentials and to update those credentials. OACC delegates authentication to registered implementations of the simple AuthenticationProvider interface.

Currently, OACC only ships with a production-ready secure password-credentials implementation, to get you started. This built-in password based authentication provider employs a number of best practices including one-way hashing, salting, binding, and lets you choose between BCrypt or Jasypt encryption.

Alternatively, you can use any authentication protocol your application requires (such as LDAP, Active Directory, OAuth, etc.) by implementing the AuthenticationProvider interface.

OACC's default built-in authentication provider is a simple, but secure password-based authentication provider implementation, to get you started. It handles password-based authentication credentials and performs the secure storage and password matching required for authentication, which includes one-way hashing, salting and binding. Currently you can choose between BCrypt or Jasypt encryption.

A PasswordEncryptor defines the password encryption algorithm to be used by the built-in authentication provider. OACC currently provides two implementations: BCrypt and Jasypt. Both are implementations of one-way password hashing functions that salt each password to make precomputation attacks infeasible and prevent duplicate hashes from revealing identical passwords. Both algorithms are adaptive in the sense that they can perform key-stretching via iterative hashing to slow down brute-force attacks and make them intractable.

The Jasypt encryptor lets you specify salt size, hashing algorithm and number of iterations, when you need a straightforward algorithm or want to fine-tune its parameters. The BCrypt encryptor uses the BouncyCastle implementation of the bcrypt reference implementation on OpenBSD, when you require a trusted and potentially stronger algorithm.

To best leverage any adaptive password hashing algorithm, you should make it "run as slow as possible without affecting the users' experience and without increasing the need for extra hardware over budget" (OWASP Password Storage Cheat Sheet), and increase the work factor/iteration count to slow down the hash computation as processing power increases over time.

OACC supplies a password encryptor that lets you transition from an existing encryption scheme to a new one, in an environment where OACC was already deployed.

Consider the use-case where you need to continue authenticating resources created prior to OACC v2.0.0-rc.8, but transition to a different password encryption scheme when storing new or resetting existing passwords:
Simply specify a TransitioningPasswordEncryptor that takes both old source and new target encryptors. The default password encryption algorithm provided prior to RC.8 is available to you as the (deprecated) LegacyJasyptPasswordEncryptor and can be used as the "old" encryptor. The "new" encryptor can be your choice of BCrypt or Jasypt. This configuration will let you authenticate old and new resources, while at the same time storing or resetting passwords only with the new encryption scheme.

Credentials are used to authenticate a resource, in order to prove that the resource trying to authenticate is in fact who it claims to be.

In the context of OACC, Credentials is the most general interface that is used to indicate that an object contains OACC credentials. The default authentication provider provided by OACC only supports the more specific PasswordCredentials sub-interface. Other custom implementations of Credentials must be paired with an implementation of AuthenticationProvider that understands the respective implementation of the Credentials interface.

If you plan to use OACC's built-in secure password authentication provider and want to prevent a cleanable char[] password being turned into a temporary String during unicode character normalization, you need to include a dependency to ICU4J, the International Components for Unicode library, which is also available from Maven with:

<dependency>
    <groupId>com.ibm.icu</groupId>
    <artifactId>icu4j</artifactId>
    <version>59.1</version>
</dependency>
                            

Note that OACC's built-in authentication provider supports cleanable passwords even with ICU4J versions prior to 4.6, by checking for the existence of the APIs that do not leak Strings and selecting the appropriate one.

If you plan to implement your own password-based authentication provider or credentials, you're responsible for enforcing your desired behavior regarding cleanable char[] passwords.

OACC is an application security framework developed by Acciente. OACC was originally developed by Acciente to provide advanced object level application security for the systems that it built for its clients. In 2014 Acciente decided to release OACC as open-source software. Acciente is excited to share OACC with the community. We are committed to the long-term success of OACC and to support its adoption in commercial organizations.

OACC is licensed by Acciente under the commercial friendly Apache License 2.0. The decision to release OACC under the Apache License 2.0 was motivated by the numerous high quality open source software projects available under commercial friendly licenses from the Apache Software Foundation, other organizations and individuals. At Acciente we appreciate the generosity of these projects and we contribute in the same spirit.

The OACC framework started life at Acciente as the Resource Security Framework (RSF). Work on the first version of RSF 1.0 was completed in 2010, and has been used in production ever since. RSF 1.0 only supported the IBM DB2 relational database for the security data repository. When Acciente decided to release RSF as open source software in 2014, work was started on a number of refactorings that became RSF 2.0. RSF 2.0 made improvements to the public API and the security data repository.

Close to the release of RSF we found that there was an existing open source project (a Java web framework) that already abbreviated to RSF. After a lot of deliberation and an intermediate name (REACC), RSF became OACC.

The OACC 2.0 security data repository now supports many popular RDBMS including DB2, SQL Server, Oracle, PostgreSQL, HSQLDB, MySQL / MariaDB, and SQLite. Part of the OACC 2.0 development effort included a comprehensive suite of tests for OACC.