Fork me on GitHub


General Notes

One of main goals for Oak security, was to clearly separates between access control management (such as defined by the JCR and Jackrabbit API) and the internal permission evaluation.

While access control management is defined to be an optional feature added in JCR 2.0, permission evaluation was mandated since the very first version of JCR even though it remained an implementation detail.

The documentation follows this separations and handles access control and permission evaluation separately:

Despite the fact that there is a distinction between the public facing access control management and the internal permission evaluation, these two topics remain connected to one another and a given authorization model is expected to define and handle both in a consistent manner. Consequently the main entry point for authorization related operations is a single AuthorizationConfiguration (see section configuration below).

API Extensions

The API extensions provided by Oak are covered in the following sections:


The configuration of the authorization related parts is handled by the AuthorizationConfiguration. This class provides the following methods:

Configuration Parameters

The supported configuration options of the default implementation are described separately for access control management and permission evalution .


There are multiple options for plugging authorization related custom implementations:

Aggregation of Different Authorization Models

Since Oak 1.4

As of Oak 1.4 the built-in SecurityProvider implementations allow for the aggregation of multiple AuthorizationConfigurations.

The behaviour of the CompositeAuthorizationConfiguration is described in the corresponding section (see also OAK-1268).

Previous Versions

In previous versions of Oak aggregation of multiple authorization models was not supported and it was only possible to replace the existing AuthorizationConfiguration. This would completely replace the default way of handling authorization in the repository.

In OSGi-base setup this is achieved by making the configuration implementation a service such that it takes precendece over the default.

In a non-OSGi-base setup the custom configuration must be exposed by the SecurityProvider implementation.

Extending the Restriction Provider

In all versions of Oak it is possible to plug custom implementation(s) for the restriction management that allows to narrow the effect of permissions to items matching a given, defined behavior. Details can be found in section RestrictionManagement.