Oak Documentation

Examples

Node content = session.getNode("/content");
if (session.hasPermission("/content/newNode", Session.ACTION_ADD_NODE)) {
     content.addNode("newNode");
     session.save();
}

Node content = jrSession.getNode("/content");
if (jrSession.hasPermission("/content", JackrabbitSession.ACTION_VERSIONING, JackrabbitSession.ACTION_LOCKING))) {
     content.checkin();
     session.save();
}

Node content = session.getNode("/content");
if (session.hasPermission("/content", Permissions.getString(Permissions.VERSION_MANAGEMENT))) {
     content.checkin();
     session.save();
}

Simple Permissions

Read operations:

• READ_NODE
• READ_PROPERTY
• READ_ACCESS_CONTROL

Write operations:

• ADD_NODE
• REMOVE_NODE
• MODIFY_CHILD_NODE_COLLECTION
• ADD_PROPERTY
• MODIFY_PROPERTY
• REMOVE_PROPERTY
• NODE_TYPE_MANAGEMENT
• MODIFY_ACCESS_CONTROL
• LOCK_MANAGEMENT
• VERSION_MANAGEMENT

Since Oak 1.0:

• USER_MANAGEMENT: : execute user management related tasks such as e.g. creating or removing user/group, changing user password and editing group membership.
• INDEX_DEFINITION_MANAGEMENT: create, modify and remove the oak:index node and it's subtree which is expected to contain the index definitions.

Repository operations:

• NODE_TYPE_DEFINITION_MANAGEMENT
• NAMESPACE_MANAGEMENT
• PRIVILEGE_MANAGEMENT
• WORKSPACE_MANAGEMENT

Not used in Oak 1.0:

• LIFECYCLE_MANAGEMENT
• RETENTION_MANAGEMENT

Aggregated Permissions

• READ: aggregates READ_NODE and READ_PROPERTY
• REMOVE: aggregates REMOVE_NODE and REMOVE_PROPERTY
• SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY
• WRITE: aggregates ADD_NODE, REMOVE_NODE and SET_PROPERTY
• ALL: aggregates all permissions

Reading

• Regular Items: Due to the fine grained read permissions Oak read access can be separately granted/denied for nodes and properties. Granting the jcr:read privilege will result in a backwards compatible read access for nodes and their properties, while specifying rep:readNodes or rep:readProperties privileges allows to grant or deny access to nodes and properties (see also Privilege Management for changes in the privilege definitions). Together with the restrictions this new behavior now allows to individually grant/deny access to properties that match a given name/path/nodetype (and as a possible extension even property value).
• Version Content: The accessibility of version content located underneath /jcr:system/jcr:versionStore is defined by the permissions present with the versionable node. In case the version information does no longer have a versionable node in this workspace it's original versionable path is used to evaluate the effective permissions that would apply to that item if the version was restored. This change is covered by OAK-444 and addresses concerns summarized in JCR-2963.
• Access Control Content Read access to access control content such node storing policy or ACE information requires READ_ACCESS_CONTROL permission.

Writing

• Property Modification: Since Oak the former SET_PROPERTY permission has been split such to allow for more fined grained control on writing JCR properties. In particular Oak clearly distinguishes between creating a new property that didn't exist before, modifying or removing an existing property. This will allow to cover those cases where a given Subject is only allowed to create content without having the ability to modify/delete it later on.
• Node Removal: As of Oak Node#remove() only requires sufficient permissions to remove the target node. See below for configuration parameters to obtain backwards compatible behavior.
• Rename: Due to the nature of the diff mechanism in Oak it is no longer possible to distinguish between JackrabbitNode#rename and a move with subsequent reordering.
• Move: The current permission evaluation attempts to provide a best-effort handling to achieve a similar behavior that it was present in Jackrabbit 2.x by keeping track of transient move operations. The current implementation has the following limitations with respect to multiple move operations within a given set of transient operations:
  • Move operations that replace an node that has been moved away will not be detected as modification by the diff mechanism and regular permission checks for on the subtree will be performed.
  • Moving an ancestor of a node that has been moved will only detect the second move and will enforce regular permissions checks on the child that has been moved in a first step.
• Managing Index Definitions: Writing query index definitions requires the specific index definition management which is enforce on nodes named “oak:index” and the subtree defined by them. Note that the corresponding items are not protected in the JCR sense. Consequently any other modification in these subtrees like e.g. changing the primary type or adding mixin types is governed by the corresponding privileges.

Writing Protected Items

Writing protected items requires specific permissions and is not covered by regular JCR write permissions. This affects:

• Set/Modify Primary or Mixin Type: NODE_TYPE_MANAGEMENT
• Access Control Content: MODIFY_ACCESS_CONTROL
• Locking: LOCK_MANAGEMENT
• Versioning: Executing version related operations and thus writing to the version store requires VERSION_MANAGEMENT permission instead of the regular JCR write permissions. Similarly, the content in the version store can only be modified using the dedicated version management API.
• User Management: By default user management operations require the specific user management related permission USER_MANAGEMENT to be granted for the editing subject. This permission (including a corresponding privilege) has been introduced with Oak 1.0. See below for configuration parameters to obtain backwards compatible behavior.

Observation

Permission evaluation is also applied when delivering observation events respecting the effective permission setup of the Session that registered the EventListener.

However, it is important to understand that events are only delivered once the modifications have been successfully persisted and permissions will be evaluated against the persisted state.

In other words: Changing the permission setup along with the modifications to be reported to the EventListener will result in events being included or excluded according to the modified permissions. See OAK-4196 for an example.