Authorization
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 consistently. Therefore, 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:
Configuration
The configuration of the authorization related parts is handled by the AuthorizationConfiguration. This class provides the following methods:
getAccessControlManager: get a new ac manager instance (see Access Control Management).getPermissionProvider: get a new permission provider instance (see Permissions).getRestrictionProvider: get a new instance of the restriction provider (see Restriction Management.
Configuration Parameters
The supported configuration options of the default implementation are described separately for access control management and permission evaluation .
Pluggability
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 precedence 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.
Best Practices
See section Best Practices for Authorization.