Difference between revisions of "Home Library: Security and user management"
(→Resource-based ACLs) |
|||
| Line 2: | Line 2: | ||
||__TOC__ | ||__TOC__ | ||
|} | |} | ||
| − | |||
| − | user & group management | + | A repository may support access control management, enabling the following: |
| − | access control management | + | *Privilege discovery: Determining the privileges that a user has in relation to a node. |
| − | + | *Assigning access control policies: Setting the privileges that a user has in relation to a node using access control policies specific to the implementation. | |
| + | |||
| + | In gCube 3.0, Home Library delivers a facility to support: | ||
| + | |||
| + | *user & group management | ||
| + | *access control management | ||
| − | == | + | ==API for security and user management== |
Jackrabbit provied and additional API for security and user management. This is about user & group management. | Jackrabbit provied and additional API for security and user management. This is about user & group management. | ||
User Manager is exposed through a | User Manager is exposed through a | ||
| − | org.apache.jackrabbit.api.security.user.UserManager | + | *org.apache.jackrabbit.api.security.user.UserManager |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Access control is exposed through a | Access control is exposed through a | ||
| − | javax.jcr.security.AccessControlManager | + | *javax.jcr.security.AccessControlManager |
| + | |||
| − | |||
===Privilege Discovery=== | ===Privilege Discovery=== | ||
| Line 45: | Line 43: | ||
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. | 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 | + | |
| + | ===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 and rep:DenyACE child nodes (usually named deny, deny0,...) for deny access control entries. | 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 and 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, and a rep:privileges NAME multi-value property, containing all the privileges of this ACE. | Each ACE node has a rep:principalName STRING property pointing to the user or group this ACE belongs to, and a rep:privileges NAME multi-value property, containing all the privileges of this ACE. | ||
| Line 61: | Line 61: | ||
Delete group | Delete group | ||
| + | Users and Groups are stored in the repository as JCR nodes. | ||
===Permissions checking from scripts=== | ===Permissions checking from scripts=== | ||
Revision as of 12:12, 30 January 2014
A repository may support access control management, enabling the following:
- Privilege discovery: Determining the privileges that a user has in relation to a node.
- Assigning access control policies: Setting the privileges that a user has in relation to a node using access control policies specific to the implementation.
In gCube 3.0, Home Library delivers a facility to support:
- user & group management
- access control management
API for security and user management
Jackrabbit provied and additional API for security and user management. This is about user & group management.
User Manager is exposed through a
- org.apache.jackrabbit.api.security.user.UserManager
Access control is exposed through a
- javax.jcr.security.AccessControlManager
Privilege Discovery
A privilege represents the ability to perform a particular set of operations on a node. Each privilege is identified by a JCR name. JCR defines a set of standard privileges within the Privilege interface.
Permissions / Privileges
These permissions, called "privileges", are defined by the JCR 2.0 specification. 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.
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:addChildNodes 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.
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 and 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, and a rep:privileges NAME multi-value property, containing all the privileges of this ACE.
Managing users and groups
HL can: List users Create user Delete user List groups Get group Create group Update group Delete group
Users and Groups are stored in the repository as JCR nodes.
Permissions checking from scripts
HL provides a service (AuthorizablePrivilegesInfo) to know what actions the current user is provisioned to do. The AuthorizablePrivilegesInfo provides methods for checking the following actions:
