Oak Documentation

Reading

The only break in terms of backwards compatibility is the accessibility of version content underneath /jcr:system/jcr:versionStore. As of Oak the access to version content depends on the read permissions present with the versionable node while Jackrabbit 2.x doesn't apply any special rule. These changes are covered by OAK-444 and address the concerns summarized in JCR-2963.

Node Removal

As of Oak Node#remove() only requires sufficient permissions to remove the target node. In contrast to Jackrabbit 2.x the validation will not traverse the tree and verify remove permission on all child nodes/properties.

In order to obtain backwards compatible behavior with respect to tree removal the permission evaluation can be configured to traverse down the hierarchy upon removal. This config flag is a best effort approach but doesn't guarantee an identical behavior.

Rename

Due to the nature of the diff mechanism in Oak it is not possible to distinguish between JackrabbitNode#rename and a move with subsequent reordering. Consequently the permission evaluation will no longer apply the special handling for the renaming as it was present in Jackrabbit 2.x (renaming just required the ability to modify the child collection of the parent node).

Move

Due to the nature of the diff mechanism in Oak it is no longer possible to treat move operations the same way as it was implemented in Jackrabbit 2.x.

For API consumers and applications running on Jackrabbit Oak this means that combinations of multiple moves can not always be properly resolved. Consequently permissions will be evaluated as if the modifications did not include move (in general being more restrictive): If the move leads to changes that are detected by the diff mechanism, regular permissions will be evaluated for all items that appear to be added, removed or modified, while a regular move operations just requires REMOVE_NODE permission on the source, ADD_NODE and NODE_TYPE_MANAGEMENT permissions at the destination.

User Management

By default user management operations require the specific user mgt related permission to be granted for the editing subject. This permission (including a corresponding privilege) has been introduced with Oak 1.0. For backwards compatibility with Jackrabbit 2.x this behavior can be turned off by setting the corresponding configuration flag.

Version Management

Reading items in the version store depends on access rights present on the corresponding versionable node. In case the version information does no longer have a versionable node in this workspace that original path is used to evaluate the effective permissions that would apply to that node if the version was restored. This changes is covered by OAK-444 and addresses concerns summarized in JCR-2963.

Repository Level Operations

Repository level operations such as namespace, nodetype, privilege and workspace management require permissions to be defined at the repository level such as outlined by JSR 283. This implies that access control policies need to be set at the null path. In contrast to Jackrabbit 2.x permissions defined at any regular path such as e.g. the root path with be ignored.