Access Control Lists V1

[resplin]

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com

AuthorizationSecurity

Table of Contents

• 1 Permissions
  
  
  
  • 1.1 Types and Aspects
  
  
  • 1.2 Grouping of permissions into Roles
  
  


• 2 ACLs


• 3 Java Doc


• 4 Voters


• 5 Performance


• 6 Implementation

Permissions

Permissions and roles are defined in an XML configuration file. They apply in the context of a particular type or aspect. These permissions and roles can be bound to authorities (groups and users) in two ways.

Firstly, as global permission definitions, in which a permission or role is simple assigned to an authority. This assignment is valid regardless of any context, and regardless of any permissions assigned to the authority in that context (ACLs). If you were to assign the 'Consumer' role to 'GROUP_EVERYONE' then everyone would be able to read content regardless of any specific permissions set on a node for this authority or how permission are inherited for the node. Global permissions are currently assigned in the same XML file as the permission model.

Secondly, there are ACLs where a permission or role is granted or denied to a given authority for a given node. By default, an ACL entry is inherited by all children of the node. 

Permissions and roles are enforced at the node level. This is best explained by considering 'Read' permission. Due to interactions with search (which indexes information at the node level) it makes sense that all properties have the same read access as the node. (If not, the values of properties could be deduced by how a readable node was found from a search on restricted properties). If you require finer grained permission for properties this can be achieved by using sub-nodes to partition those properties. Permissions that affect mutability could be enforced at the attribute level but they are not.

Applying read ACLs at the property level would require a change to the indexing implementation or a complex post analysis to work out how nodes were matched in the search and to remove properties that should not be seen. This could be done by integrating permissions in the lucene search. For example, defining a lucene query object that supports permission checks and wrapping all properties that can support specific ALCs with the normal query and a permission query.

The best compromise is to index as we are now but only allow different read access for properties that are not indexed - so their content can not be determined via query. Alternatively, only index properties etc that have the same access permissions as the node.
In both cases the content can not be determined from the index. We could have additional indexing to support searching against these restricted properties.

Types and Aspects

Types and aspects define the permissions that are associated with them in XML configuration files. This is separate to the data dictionary and can be regarded as an augmentation.

In the alfresco implementation, a permission or role is defined by a name scoped by the fully qualified name of the type or aspect.

The permissions and roles available will depend on the node types and what aspects have been applied to the node.

Grouping of permissions into Roles

We support collections of permissions as roles. These definitions are defined in XML.

Some role assignments are dynamic; such as giving the owner of a node a particular role. In this case there is a dynamic authority. When a permision check is carried out an evalutaion takes place to determine if the current user owns the node. If they do, they get assigned the owner authority and therefore they have any roles and permissions assigned to the owner authority.

Permission and role checks are coaaried out against the actual permission required. To have the role of Contributor you only need the permissions it comprises. You do not need to be explicitly assigned that role - if you have enough permission - by whatever means - you have the role.

ACLs

An ACL

• allows or denies deny access
  

for a given

• authority - user or group
  

for

• a given permission or role.
  

There is a group that includes all user except guest. Assigning some roles may grant all rights.

By default permissions are inherited from the parent unless this is explicitly denied.

Java Doc

Ownable Service

Permission Service

Access Permission

Permission Reference

Permission Entry

Voters

• RoleVoter - use Acegi
  
• ACLEntryVoter
  
• ACLEntryAfterInvocationProvider
  

RoleVoter

ACLEntryVote recognises:

• StoreRef - use root node;
  
• NodeRef - use node ref;
  
• ChildAssocRef - use child node ref;
  

for extracting the context node.

ACLEntryAfterInvocationProvider recognises:

• StoreRef - use root node;
  
• NodeRef - use node ref;
  
• ChildAssocRef - use child node ref;
  
• FileInfo;
  
• ResultSet;
  
• Collection;
  
• Object[];
  

For applying security to return parameters of function calls.

Performance

1. Initially rely on the L2 cache (done)
   
2. Cache permission evaluations (done)
   
3. Implement a bridge table
   
   • parent
     
   • child
     
   • isLeaf
     
   • isTop
     
   • level
     
   • hasPermissionEntries
     
4. Cache and preload directory entries that have permissions set
   
5. Implement read permission checks as part fo teh query which could also support property level security
   

Implementation

• Store node permissions in hibernate
  
• Define permissions model in xml
  
• Usename, role group mappings via hibernate