Controlling User Access

The Access Control Editor provides the option to control user access, e.g. for reading or modifying folders and documents and to give permission on access control settings on these. Please note that document permissions on folders are working recursively, thus if modify access to a folder is not permitted, none of the documents in this folder or sub-folders can be modified.

The Access Control Editor is opened via the Security Settings option in a Document context menu. Refer to section Setting Security of chapter Document Operations for details.

The editor contains the following two tables:

Access Control Editor
Figure: Access Control Editor

Note
To use security with Jackrabbit in the rapid application environment, you have to enable security settings as described in the following section.

Enabling Security in RAD

To make security work with Jackrabbit, perform the following steps:

  1. Stop the server
  2. In folder carnot-jackrabbit/WEB-INF/jackrabbit:
  3. In folder carnot-jackrabbit/WEB-INF/config/ipp/spring:
  4. Create a new Jackrabbit repository
  5. Republish and restart the server

Security Files
Figure: Replaced security files in RAD.

Policies on Folder Creation

Please note that implicit policies are only set on folder creation with the security enabled. In case you set the security after a folder is already created from a non security enabled repository access, the policy is not retroactively set. A user without administrator role does not have access to this folder. In this case a user with administrator role has to set policies on the folder manually. For example to make it possible to upload documents, policies on the folder /process-instances have to be set manually if it was created before the security setting.

For the following folder pattern, the permission ALL is set on creation for everyone in case security is enabled:

Using Repositories created with Versions earlier than 9.0.24.0

Since version 9.0.24.0, document centric access control evaluation is included in a newly created security Jackrabbit repository. In case access control has been set for files individually, access control is now evaluated separately without folder hierarchy inheritance.

If you like to use this feature, but you are using a repository created with an earlier version, you need to configure the AccessControlProvider inside a WorkspaceSecurity tag after the SearchIndex entry for each workspace. In this case add the following workspace security section to the workspace template creation entry in your repository.xml security file:

<Workspace name="${wsp.name}">
   ...
   <!-- Search index and the file system it uses -->
   <SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
      ...
   </SearchIndex>
   ...
   <!-- Workspace Security -->
   <WorkspaceSecurity>
      <!-- Files with ACLs are evaluated separately without Folder hierarchy. -->
      <AccessControlProvider class="org.apache.jackrabbit.core.security.authorization.acl.FileACLProvider" />
   </WorkspaceSecurity>

Note that for existing repositories the same entry needs to be added in the workspace.xml file, which resides in the according repository path, to become effective.

Participant Permissions

The following permissions are provided for participants:

Inherit: inherit permission for according action on folder/document

Allow: allow according action on folder/document

Deny: deny according action on folder/document

Inherited Permissions

Documents and folders inherit permissions from their parent folders. Note that entries of inherited permissions are not editable in the table.

Inherited Permissions on Folders

The following columns are listed for inherited permissions on folders:

Access Control Editor - Inherited Permissions
Figure: Inherited Permissions for a folder.

The table columns to be displayed can be selected individually by clicking the icon to open the Select Columns dialog. This dialog is described in chapter Selecting and Reordering Columns in Tables.

Default inherited folder permissions

Per default, inherited permissions for Administrators and Everyone are set. Administrators have the grant Allow for all permissions. Everyone has an Allow value set for the reading grant, whereas all other permissions for Everyone are Inherit (indicated by three dashes) by default.

Inherited Permissions on Documents

The following columns are listed for inherited permissions on documents:

Access Control Editor - Inherited Permissions
Figure: Inherited Permissions for a document.

Note
Once you give a document individual permissions, the inherited permissions from the parent folder are ignored!

Default inherited document permissions

Per default, inherited permissions for Administrators and Everyone are set. Administrators have the grant Allow for all permissions. Everyone has an Allow value set for the reading grant, whereas all other permissions for Everyone are Inherit (indicated by three dashes) by default.

Granted Permissions

Depending on whether the Access Control Editor was opened for a folder or for a document, one of the following tables are available:

The table columns to be displayed can be selected individually by clicking the icon to open the Select Columns dialog. This dialog is described in chapter Selecting and Reordering Columns in Tables.

The following operations on permissions are provided:

Granted Permissions on Folders

Granted permissions on folders have a table with the following columns:


Access Control Editor - Granted Permissions
Figure: Granted Permissions on a Folder

Granted Permissions on Documents

Granted permissions on documents have a table with the following columns:


Access Control Editor - Granted Permissions
Figure: Granted Permissions on a Document

Adding Participants

To add a participant to change the permission of, click the Add Participants icon in the toolbar.

The Select Participant dialog opens. The allowed participants are role, organization, department and its sub-organization and children.

Select a Participant.
Figure: Select a Participant

Select the participant in the table or click the link Pick from Tree. The participant tree gets displayed, where you can select the participant from.

Select a Participant
Figure: Participant Tree

The selected participant is created in the table with editable permissions.

Added Participant
Figure: Participant added to table

Note that the access can be granted to a role but when the role is scoped, the accessing user's scope that is department is also displayed. So, if a user would not be allowed to see or work with a process instance due to department association then similarly, the access to the process attachment is denied to that user.

Removing Participants

To remove selected participant(s) from the permissions table, you can either:

Selecting one or more participant(s) in the table is done by clicking directly on the according row(s). For details on selecting rows in tables, refer to chapter Selecting Rows in a Table. Note that administrators cannot be removed and will remain even in case all rows are selected.

Editing Permissions

To edit selected permission(s) you can do one of the following:

Now the permissions for the participant(s) can be edited.

Edit Permission Result
Figure: Permissions can be edited now.

You can switch the granted permissions in the columns between the following values provided in the drop-down list:

Permission
Figure: Set the Permission.

Click Apply to apply your changes.

Available Keyboard Shortcuts

Please refer to https://github.com/ajaxorg/ace/wiki/Default-Keyboard-Shortcuts for a an overview on provided keyboard shortcuts in the Access Control Editor.