Home Library: Security and user management

Starting from gCube 3.0, Home Library delivers Access Control Management, with the following:

• User & group management: To create, update and delete users and groups in the JCR. Users and Groups are stored in the repository as JCR nodes.
• Assigning access control policies: Setting the privileges that a user has in relation to a node using access control policies.
• Privilege discovery: Determining the privileges that a user has in relation to a node.

JCR 2.0 delivers Access Control Management. The JCR API package is javax.jcr.security. It covers the authorization part, ie. what a certain user is allowed to do with the repository.

Jackrabbit provides an additional API for security and user management located in org.apache.jackrabbit.api.security.user.

Managing users and groups

Using the Home Library that contains JCR APIs, you can create, update and delete users and groups.

The HL administator can:

• List users
• Create user
• List groups
• Get group
• Create group
• Update group
• Delete authorizable (user or group)

Example:

import org.gcube.common.homelibrary.home.workspace.usermanager.UserManager;
import org.gcube.common.homelibrary.home.workspace.usermanager.GCubeGroup;
.....
public class TestUserManager {
   private void test() {
		UserManager gm = HomeLibrary.getHomeManagerFactory().getUserManager();
		....
	}
...

List users

To list existing users:

List<String> listUsers = gm.getUsers();
for (String user: listUsers)
  System.out.println(user);

Create user

To create a new user by username and password:

gm.createUser(username, password);

List groups

To list existing groups:

List<GCubeGroup> listGrroups = gm.getGroups();
for (GCubeGroup group: listGrroups)
 System.out.println(group);

Get group

The properties of a single group can be retrieved by calling the method getGroup, where groupname would be replace with the name of the group.

GCubeGroup myGroup = gm.getGroup(groupname);
String groupname = myGroup.getName();
List<String> members = myGroup.getMembers();

Create group

To create a new group, where groupname would be replace with the name of the group.

gm.createGroup(groupname);

Update group

The name of the group can NOT be updated, only the membership is updateable. The following methods are available:

myGroup.addMember(member);
myGroup.removeMember(member);
myGroup.addMembers(members);
myGroup.removeMembers(members);

Delete group

To delete an existing user or group:

gm.deleteAuthorizable(user);

Managing permessions

Permissions, called "privileges", are defined by the JCR 2.0 specification.

A privilege represents the ability to perform a particular set of operations on a node. This is basically the set of read, create, modify and delete operations that can be done on nodes and properties via the JCR API. A repository can also define custom privileges.

Permissions / Privileges

Basic privileges:

• jcr:read: The privilege to retrieve a node and get its properties and their values.
• jcr:modifyProperties: The privilege to create, remove and modify the values of the properties of a node.
• jcr:addChildNode: The privilege to create child nodes of a node.
• jcr:removeNode: The privilege to remove a node.
• jcr:removeChildNodes: The privilege to remove child nodes of a node.
• jcr:write: An aggregate privilege that contains:
  • jcr:read,
  • jcr:modifyProperties,
  • jcr:addChildNodes,
  • jcr:removeNode,
  • jcr:removeChildNodes
• jcr:all: An aggregate privilege that contains all available permissions, including:
  • jcr:read,
  • jcr:write and the advanced permssions.

ACL Model

Resource-based ACLs

Resource-based ACLs are the default access control mechanism in Jackrabbit 2.x. That means that a resource = node is associated with a list of allow/deny entries for certain principals (users or groups), which naturally maps to store them along the JCR node. A core concept of resource-based ACLs is that they inherit the ACLs from the parent node, thus for each node, all the ACLs of its ancestor come into play as well.

How Resource-based ACLs are stored

Resource-based ACLs are stored per resource/node in a special child node rep:policy. This one will have a list of:

• rep:GrantACE child nodes (usually named allow, allow0,...) for grant access control entries
• rep:DenyACE child nodes (usually named deny, deny0,...) for deny access control entries.

Each ACE node has

• a rep:principalName STRING property pointing to the user or group this ACE belongs to
• a rep:privileges NAME multi-value property, containing all the privileges of this ACE.

gCube Permissions

We will have 4 specific permissions for shared folders:

• Read-only: this permission the ability to read the files in the shared folder.
• Write-owner': this permission grants the ability to create and modify their own files. This includes the creating, deleting, moving and renaming, just for the own files.
• Write-all: this permission grants the ability to modify the content of a shared folder. This includes creating files, deleting files, moving files and renaming files. It will not be allow to delete the shared folder root.
• Administrator: this permission grants the ability to perform every actions on the shared folder. An administrator can delete the shared folder root too.

Repository Configuration

To use the Resource-based ACL mechanism, a different AccessControlProvider has been configured. This is set in the <Workspace/> element of the repository.xml.

    <WorkspaceSecurity>
        <AccessControlProvider class="org.apache.jackrabbit.core.security.authorization.acl.ACLProvider" />
    </WorkspaceSecurity>

In addition, the LoginModule has been modified to use the DefaultLoginModule that authenticates users with Jackrabbit repository:

    <LoginModule class="org.apache.jackrabbit.core.security.authentication.DefaultLoginModule">
        <param name="adminId" value="xxx" />
        <param name="adminPassword" value="xxx" />
    </LoginModule>

Permissions checking

Home Library provides a Class (PrivilegesInfo) to know what actions the current user is provisioned to do on an existing node. The PrivilegesInfo provides methods for checking the following actions:

• addChildren(jcrSession): Checks if the current user may add new nodes;
• canModifyProperties: Checks if the current user may update the properties of the specified node;
• canDelete: Checks if the current user may remove a specified node.

Every time a user does an action in the Workspace (move, create, rename, delete or update files), the HL will check if such user has the privilege to perform that.