Version 0.4
Access Control Lists
Proposal for Access Control Lists in CMIS
18/02/2008
Versions
Version
Authors
Date
Changes
0.1
Paul Goetz, SAP
12/09/2008
document created
0.2
Florian Müller, Open Text
Jens Hübel, Open Text
Viktor Gavrysh, EMC
Martin Hermes, SAP
Paul Goetz, SAP
12/16/2008
completely restructured
0.3
Paul Goetz, SAP
12/18/2008
motivation added, minor changes,
maps for required extend permission per operation added
0.4
Paul Goetz, SAP
02/18/2008
adapted to findings from CMIS Faces2Face 28/01/2008,
extended permission model removed
ACL Proposal 0.4
2
CONTENTS
Contents ........................................................................................................................................................................3
Introduction ...................................................................................................................................................................5
Recap: Security In CMIS Specification 0.5 ..................................................................................................................5
ACL Design objectives ................................................................................................................................................5
Relation to Other Standards ......................................................................................................................................7
General Concepts ..........................................................................................................................................................9
Overview of ACLs .....................................................................................................................................................10
Data Model ..................................................................................................................................................................14
Discovering ACL Capabilities ....................................................................................................................................14
Object Services ........................................................................................................................................................14
ACL Services .............................................................................................................................................................14
Checking Privileges ..................................................................................................................................................19
Changes to the Specification ...................................................................................................................................19
Required permissions per operation ...........................................................................................................................20
Overview ..................................................................................................................................................................20
Object Service ..........................................................................................................................................................21
Repository Service ...................................................................................................................................................23
Navigation Service ...................................................................................................................................................24
Multifiling Service ....................................................................................................................................................24
Discovery Service .....................................................................................................................................................25
Versioning Service ...................................................................................................................................................25
RelationShip Service ................................................................................................................................................26
Policy Service ...........................................................................................................................................................26
ACL Proposal 0.4
3
ACL Proposal 0.4
4
INTRODUCTION
While the CMIS specification defines a generic policy model, this proposal is about Access Control Lists (ACLs) as a
specific service beside the policy model and how it can be added to the CMIS.
RECAP: SECURITY IN CMIS SPECIFICATION 0.5
Version 0.5 of the CMIS specification draft introduces a concept of policy objects. Access to certain methods of an
object can be restricted by a policy.
Policies – like other primary entities of the CMIS specification – are typed, have an object ID and have properties
(see General Concepts below).
A policy is created using the ObjectService’s createPolicy method. Input for this method is a description of the
policy (name, type, properties, etc.), output is an ID of the created policy instance. Providing this ID, a policy can
be applied to a controllable object (applyPolicy), removed (removePolicy), or retrieved from an object
(getAppliedPolicies) via the Policy Service.
A controllable object can have zero or more policies applied. Not having a policy applied means that there exist no
restrictions in accessing the object.
ACL DESIGN OBJECTIVES
In order to clarify the requirements for ACLs, we tried to classify applications and their security requirements in
three szenario types:
1.
Collaborative applications – like Collaborative Content Creation, Portals, Mashups – where an end user
decides about the permissions to be applied to the documents at runtime.
(e.g. “My working drafts for the documentation should only be editable by my co-workers John and Mary, be
visible to my team, but they must not to be seen by someone else outside the team”.)
2.
Background tasks – like an archiving application – where a developer has to specify the permissions to be
applied at designtime.
(e.g. “Documents moved by the archiving service become read-only, except for the special group ‘archive
admin’”.)
3.
Business applications – like attaching the scanned images of an invoice to ERP data – will require application
specific security.
(e.g. “Invoices with a total of more than 1M$ should not be visible by anyone who’s not a member of the
controlling team and has doesn’t have at least a clearance level 2”.)
ACL Proposal 0.4
5
As szenarios 1 and 2 are the “Core ECM” use cases for CMIS, we will focus on these kind of use cases.
Szenario 3 is considered as being out of scope for CMIS, thus we will not try to provide a solution for this kind of
scenarios. We assume that policies are a better choice to handle this kind of specific security constraints anyway.
Szenario-2-type applications would need to know about the semantics of the policies to be applied already during
designtime, thus some semantics have to be defined. And although szenario-1-type applications 1 do not
necessarily need to know about the semantics (since the end user has to deal with the permissions, not the
application itself), some semantics would be helpful as well.
This results in the following requirement:
A developer should be able to work with permissions for CMIS objects in an interoperable manner at designtime,
without additional assumptions about the repository be used at runtime.Therfore, ACLs imply at least a basic
semantic in terms of “who is allowed to do what” – in the scenarios above, the who is known by the application, so
this proposal will focus on the what (the permissions).
One of these use cases for a szenario-2-type application is “Unified Search”: Data from an CMIS repository is to be
indexed by an external search engine. In order to be able to filter the relevant results for a given user, the search
engine should be able to index some information about “who will be allowed to see the search result” while
indexing (e.g.: while indexing, the ACL entries for READ permissions can be indexed as well, then the search query
could be extended to something like WHERE … AND currentuser IS IN read-acl-entries).
There are basically two different options how the semantics of permissions can be made predefined for the
application: Either there is one permission model already predefined by CMIS (the applications and the
repositories would have to map their permissions to that “standard”, requiring potentially 1:n mappings for the
applications and 1:m mappings for the repositories). Or the mapping of the permissions is done for potentially
every combination of application and repository (resulting in n:m-mappings, either to be handled by the
application or the repository).
The second options allows for more flexibility – but requires more mappings and therefore more administrative
effort than the first option, so this proposal tries to provide a minimal approach for the first option. But as there
are different requirements for the different types of applications yet, we will have to support both options.
Therefore we suggest to divide the requirements for handling policies and permissions in three different levels
(related to the three application szenario types above):

Level 0 = Applications working with policies only.
 security defined via generic policy (for business applications, szenario type 3 above)
 for interoperability this will require a notation for specifying generic policies in an interchangeable
format (e.g. using XACML)
 out of scope for this proposal
ACL Proposal 0.4
6

Level 1 = Applications using ACLs with a flexible mapping of permissions per repository.
 security defined via ACL, where permissions are unknown to the application (for end user applications,
szenario type 1 above)
 will require mappings either on the application or the repository side, thus requires at least the
capability to discover the available permissions
 will be refered to as Level-1-ACLs or Generic ACLs

Level 2: Applications using ACLs with a fixed mapping of permissions.
 like Level 1, but permissions are known to the application (e.g. unified search or application specific
permissions, szenario type 2 above)
 requires mappings on the repository side, the known permissions are predefined by CMIS
 will be refered to as Level-2-ACLs or CMIS-Defined or Basic ACLs.
As the ACEs of an ACL define who is allowd to do what, two additional assumptions:
1.
Regarding the who:
We assume that all the systems share a common understanding of the principals to be checked. In an
enterprise or intranet scenario, this is more likely to be the case, as a central LDAP or other kind of directory
service will most probably be available. For extranet/internet scenarios, we assume that more generic
authentication standards will be relevant (in the worst case, the CMIS consumer would have to do the user
mapping by means beyond the scope of CMIS).
 We assume that principals are known to both, consumer and provider – thus user/group discovery is not
within the scope of this document.
2.
Regarding the what:
We assume that ACLs are applied to folder- and document-like objects only, and that checks against ACLs are
performed for operations on those objects only.
 We assume that ACLs are appropriate for the basic object types folder and document (not for relationship,
policy) as this concept is known from existing file system implementations – other CMIS objects would have to
be secured by policies then.
RELATION TO OTHER STANDARDS
Content Repository for Java – JSR 283
Reference: http://jcp.org/en/jsr/detail?id=283
As we expect that JCR might serve as a local Java API for the CMIS protocol (either for consumers – using JCR to
access a CMIS provider – or for providers – using CMIS to expose a JCR repository), the ACL concepts proposed by
CMIS should be mappeable to JCR:
ACL Proposal 0.4
7
Level 0 (Policies) can be mapped to the JCR’s AccessControlPolicy objects and handling of policies can be mapped
to the AccessControlManager’s get…/set…/delete… methods (while CMIS’ addPolicy could be mapped to a
getApplicablePolicies on a specific system path, or createing a node with a specific structure (e.g. using XACML)).
Level 1 (Generic) ACLs are not covered by JCR –would have to be mapped to JCR policies as well.
Level 2 (Basic) ACLs should be mappable, by taking care that the semantics defined in this proposal are compliant
with the JCR’s standard privileges jcr:read, jcr:setProperties, jcr:addChildNodes, jcr:removeChildNodes, jcr:write,
jcr:getAccessControlPolicy, jcr:setAccessControlPolicy, and jcr:all. See Permissions below.
HTTP Extensions for Distributed Authoring – WebDAV
Reference: http://www.ietf.org/rfc/rfc2518.txt, http://www.webdav.org/acl/, and
http://www.webdav.org/specs/rfc3744.html
As we assume that a CMIS providers might also expose its repository via WebDAV, the proposed ACL concept
should be mappeable to WebDAV.
Level 0 (Policies) are not covered by WebDAV.
Level 1 (Generic) ACLs are pretty much the same as specified in WebDAV, using specific privileges (aka
permissions).
Level 2 (Basic) ACLs use a simplified set of privileges which can be mapped as well. See Permissions below.
XACML
Reference: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml#XACML20
XACML is much more generic and flexible then the proposed ACLs. As outlined above, we consider more generic
security handling and policies as being out of scope for this proposal.
Thus – although XACML might become relevant when getting into more details for policies or the discovery of
permissions – we won’t take XACML into account for this proposal.
ACL Proposal 0.4
8
GENERAL CONCEPTS
To provide an overview about the general concept and to provide a more formal naming, the following sections
use a Java style pseudo code to illustrate the proposal.
The CMIS specification currently defines the following object hierarchy:
Property
CMIS
Object
Content
Stream
has
has
*
extends
0..1
Document
Folder
Relationship
Policy
*
Contentallowable
Queryable
Source
Target
Versionable
has
has
Fileable
Controllable
*
controlled by /
applied to
A [CMIS] Object is either a Document, a Folder, a Relationship or a Policy. All of them may have Properties
assigned, while only documents may have a content (i.e. can be a Contentallowable) and are Versionable. Folders
and documents are Queryable and Fileable. Relations can reference to a a Source object and a Target object.
Documents, folders, relationsships and policies might be Controllable which may be controlled by zero or more
policies. Vice versa, a policy may be assigned to zero or several controllables.
ACLs shall be added as a specific object type, thus the propsed changed object hierarchy would look like:
ACL Proposal 0.4
9
Property
CMIS
Object
Content
Stream
has
has
*
ACL
extends
0..1
0..1
Document
Folder
Relationship
Policy
*
Contentallowable
Queryable
Source
Target
Versionable
has
has
Fileable
Controllable
*
ACLControllable
controlled by /
applied to
controlled by /
applied to
Only Documents and Folders may be ACLControllable. An ACLControllable may then be controlled by one ACL
(can have an ACL assigned). If no ACL is assigned, no permission is granted (unless specified differently by a policy
applied to the object).
An ACL in turn is implicitly assigned to its object – an ACL is not a [CMIS] Object on its own, an ACL depends on the
[CMIS] Object it belongs to (like a Property, but in contrast to Policies).
Objects may have an ACL assigned – but only if they are “tagged” as being ACLControllable.
OVERVIEW OF ACLS
Access Control Lists
An Access Control List (ACL) is a list of Access Control Entires (ACEs):
public List<AccessControlEntry> AccessControlList;
ACL Proposal 0.4
10
Access Control Entries
An Access Control Entry (ACE) specifies a permission and a principal.
public class AccessControlEntry {
public String PrincipalId;
public String PermissionName;
public Boolean isInherited;
}
This proposal restricts to positive ACEs. Thus, no negative flag is required.
See also Permissions below for more details on the PermissionName.
Since an ACE is specified by it’s prinicpal’s ID and the permission’s name, “changing” an ACE means either
removing an existing ACE (PrincipalID,PermissionName) or adding a new ACE (PrincipalID,PermissionName).
The isInherited flag indicates that the ACE is applied to the document or folder itself (isInherited=false), or is
derived or inherited from another object (isInherited=true). The isInherited flag is provided when the ACL is
retrieved from the repository – it is not relevant (can be omitted) when a client specifies an ACE to be applied to
an document or folder.
For more details, see Discovering ACL Capabilities and Applying ACES below.
Principals
A principal represents either a single user, or a set of users – this can be a group, or some other notion like a
“role”.
While the principal ID is just an opaque string to the client, we assume that every system has some kind of user
management, which is able to retrieve the relevant information from the central LDAP or directory service for a
given principal ID:
public class UserManagement {
public SecurityPrincipal getPrincipalByID(String id);
}
For this usermanagement objects, we assume that at least checks for equality are available:
public interface SecurityPrincipal {
public String getPrincipalID();
public boolean equals(SecurityPrincipal user);
}
For a set of users, we assume that at least a check to determine if a given user is contained in that set (direct or
indirect in a subset contained in the set) is available:
public interface SecurityPrincipalSet extends SecurityPrincipal {
ACL Proposal 0.4
11
public boolean contains(SecurityPrincipal user);
}
Permissions
As outlined in the DESIGN OBJECTIVES, the goal for this proposal is to specifiy an interoperable permission model –
at least providing mechanisms enableing applications to discover the “meaning” of the permissions provided by
the repositories; or if possible to specify a predefined set of permissions.
As this is relevant for the applications of category 2 (described above), this proposal is about a minimal set for
those type of applications only:
All
Write
Read
At least this three permissions (All, Write, Read) should to be exposed by a repository as a minimal set.
The arrows show the “include”-relations for the permissions: The permission All includes all other permissions,
thus if All is assigned to a user, this includes all other permissions. Write in turn includes Read.

All: includes all other permissions.
(corresponding to jcr:all or DAV:all)

Write: permits to change the permission of the given object, to delete the object, write properties and
content of the object, as well as filing or unfiling (plus Read, see below).
(corresponding to jcr:setAccessControlPolicy+ jcr:write+ jcr:setProperty+ jcr:addChildNodes+
jcr:removeChildNodes or DAV:write-acl+DAV:write)

Read: permits to read the permission of the given object, to read properties and content of the given
object.
(corresponding to jcr:getAccessControlPolicy+jcr:read or DAV:read-acl+ DAV:read-current-user-privilegeset+DAV:read)
As this are the most basic Permissions, which might be changed to more specific ones in the future, the proposal is
to name them accordingly: CMIS.BasicPermission.All, CMIS.BasicPermission.Write, and
CMIS.BasicPermission.Read.
This proposal restricts to positive ACEs. Thus, a NONE permission is not required, as this is the default permission
for a principal not being listed in an ACE (direct or via PrincipalSet, see below).
ACL Proposal 0.4
12
For an application consuming CMIS ACLs, it might be helpful to distinguish between the different “levels” of
permissions (see ACL Design objectives above), so we propose the following naming.
A Level-1-ACL or GenericACL has ACEs with repository specific permission assigned – i.E. for a GenericACL there
may be several ACEs with PermissionName not in { CMIS.BasicPermission.All, CMIS.BasicPermission.Write,
CMIS.BasicPermission.Read } (but it also might support ACEs with these specified CMIS permissions, if the
repositories semantics match those of the CMIS permission).
For a Level-2-ACL or BasicACL, all the ACEs’ PermissionName are in { CMIS.BasicPermission.All,
CMIS.BasicPermission.Write, CMIS.BasicPermission.Read } and match the specified semantics.
E.g. an ACL like {(john: CMIS.BasicPermission.All), (mary: bind), (mary:unbind),
(mary:write)} would be a GenericACL, since bind- and unbind-permission would not be specified by CMIS.
An ACL like {(john: CMIS.BasicPermission.All), (mary: CMIS.BasicPermissionWrite)}
would be a BasicACL then.
By default, if no ACL is assigned to an object, no permissions are granted at all (unless overwritten by a policy like
“everybody has all-permission for objects without ACL”).
As this proposal is about using positive ACEs only, access is restricted according by ACL as follows: If no ACE exists,
where the given user matches*) the ACE’s principal entry, access is denied.
*)
Matching means something like
ace_principal = UserManagement.getPrincipalByID(ACE.getPrincipalID());
matches = ace_principal.equals(user)
|| ((ace_principal instanceof SecurityPrincipalSet)
&& ((SecurityPrinicpalSet)ace_principal).contains(user));
ACL Proposal 0.4
13
DATA MODEL
A new optional enum ACLControllable needs to be added to the “Basic Object Types”, which may have one
of the following values for Documents and Folders (and is not existend for Relations and Policies): GenericACL
and BasicACL (others might be added later).
A new enum is required to describe the operation mode when applying ACLs: enumACLSetType with Type
String and the Values object-only, dont-care, and propagate.
For the ACL and ACE, see Access Control Lists and Access Control Entries above.
DISCOVERING ACL CAPABILITIES
RepositoryService.getRepositoryInfo must return some information, if the repository supports ACLs at all – either
generic (Level 1), or specific (Level 2 – and then: what subset of the predefined set).
An additional Property capabilityACLSupport MAY be returned by the Repository Service when getRepositoryInfo
is called. This property is a singlevalued Boolean property, holding true if ACLs are supported at all.
An additional Property capabilityACLSupportPermissions MUST be returned by the Repository Service when
getRepositoryInfo is called and if capabilityACLSupport contains GenericACL (MAY be omitted otherwise). This
property is a multivalued String property, which lists the permissions known to the repository.
An additional Property capabilityACLSupportSetType MUST be returned by the Repository Service when
getRepositoryInfo is called and if capabilityACLSupport is returned (MAY be omitted otherwise). This property is a
multivalued String property, each with the same type as enumACLSetType (see above): a String enum with
the Values object-only, dont-care, and propagate, which indicates that setACL can be controlled via
enumACLSetType.
OBJECT SERVICES
createDocument and createFolder need to be extended with an additional Input: (Optional) ACL: A list of ACEs.
ACL SERVICES
ACL Proposal 0.4
14
getACL
Description
Inputs
Returns the ACL of an object, and optionally the operations that the user is allowed to
perform on the object






Outputs





Exceptions
Notes







ID repositoryId: Repository Id
ID objectId
(Optional) Enum returnVersion: This (Default), Latest, LatestMajor
(Optional) String filter: Filter for properties to be returned
(Optional) Boolean includeAllowableActions: False (default)
(Optional) Enum includeRelationships: none (default), source, target, both
String enumACLType
Collection ACECollection
(Optional) Collection propertyCollection (if a filter was provided)
(Optional) Collection allowableActionCollection (if includeAllowble was True)
(Optional) Colletion relations (if includeRelationships was not none)
Common Exceptions
FilterNotValidException
If “includeAllowableActions” is TRUE, the repository will return the allowable actions
for the current user for the object as part of the output.
"IncludeRelationships" indicates whether relationships are also returned for the
object. If it is set to "source" or "target", relationships for which the returned object is
a source, or respectively a target, will also be returned. If it is set to "both",
relationships for which the returned object is either a source or a target will be
returned. If it is set to "none", relationships are not returned.
Does not return the content-stream of a document
ACECollection includes changeToken (if applicable to repository)
PropertyCollection includes changeToken (if applicable to repository)
Questions
setACE
Description
Applies an ACL to an object, an existing ACL is overwritten
Inputs





ACL Proposal 0.4
ID repositoryId: Repository Id
ID objectId
(Optional) String changeToken
Collection ACECollection
(Optional) String enumACLSetType
15
Outputs
Exceptions






Notes




ID objected
String enumACLType
Collection ACECollection
Common Exceptions
UpdateConflictException
Preserves the ID of the object
If an attempt is made to update an ACL with ACEs /enumACLSetType which does not
match the repositories capabilities (e.g. enumSetACLSetType=set-object requested,
but capabilityACLSupportSetType = false and not supported), throw
ConstraintViolationException.
If a ChangeToken is provided by the repository when the object is retrieved, the
change token MUST be included as-is when calling setACL.
If this is a private working copy, some repositories may not support setACL.
no new Document Versions is created.
Questions
APPLYING ACES
If a repository is not capable to deal with changes to inherited ACEs (see Discovering ACL Capabilities), it does not
return a value for capabilityACLSupportSetType – the list of values returned are the allowed values for the input
parameter enumACLSetType for setACL.
In general we assume that the repository supports ACLs (capabilityACLSupport = true) , the repository supports
the ACE’s permission (capabilitiyACLSupportPermission contains ACE.PermissionName), the repository
supports the requested operation mode for setACL (capabilityACLSupportSetType contains the required operation
mode for enumACLSetType, and the objects type supports ACLs (type.ACLControllable is set).
The following rules apply when setting ACEs:
An ACE can be added to an ACL if:
it does not yet exist
or
exists and isInherited = false
or
exists and capabilityACLSupportType contains the enumACLSetType provided on setACL
An ACE can be removed from an ACL if:
isInherited = false
or
capabilityACLSupportType contains the enumACLSetType provided on setACL
If a repository does not support inheritance (capabilityACLSupportType does not contain any value of
enumACLSetType), an ACE with isInherited = false can not be deleted.
ACL Proposal 0.4
16
ACEs passed as input to setACE are merged with the ACEs of the existing ACL according to the rules above.
For example:
ACE 1
folder X
ACE 2
x ACE 1
folder Y
x ACE 2
ACE 3
document D
x ACE 1
x ACE 2
x ACE 3
ACE 4
Adding or removing an ACE to document D results in a ACE with isInherited = false – enumSetACLType is not
regarded.
E.g. adding ACE5 to D results in ACE5 being added to D’s ACL (ACL provided to setACL = ACE1,ACE2,ACE3,ACE4).
ACE 1
folder X
ACE 2
x ACE 1
folder Y
x ACE 2
ACE 3
document D
x ACE 1
x ACE 1
x ACE 2
x ACE 2
x ACE 3
x ACE 3
ACE 4
ACE 4
ACE 5
Adding an ACE to folder Y (or folder X) results in an ACE with isInherited = false for the given folder only – without
adding ACEs to its descendants, if enumACLSetType = object-only (or dont-care).
Adding an ACE to folder Y (or folder X) results in an ACE with isInherited = false for the given folder, but also results
in an added ACE with isInherited = true for all of it’s descendants (document D for folder Y, folder Y and document
D for folder X), if enumACLSetType = propagated (or dont-care).
E.g. adding ACE5 to X (ACL provided to setACL is ACE1,ACE2,ACE5) results in ACE5 being added to X for
enumSetACLType = object-only; in ACE5 being added to X and inherited to Y and D for enumSetACLType =
propagate; in ACE5 being added to X and a repository specific behavior for enumSetACLType = dont-care:
ACL Proposal 0.4
17
object-only
folder X
folder Y
document D
dont-care
ACE 1
ACE 1
ACE 1
ACE 2
ACE 2
ACE 2
ACE 5
ACE 5
x ACE 1
x ACE 1
x ACE 2
x ACE 2
ACE 3
ACE 3
x ACE 1
x ACE 1
x ACE 2
x ACE 2
x ACE 3
x ACE 3
ACE 4
ACE 4
propagate
ACE 1ACE 1
ACE 1
ACE 2ACE 2
ACE 2
ACE 5ACE 5
ACE 5
x ACE 1 x ACE 1
x ACE 1
x ACE 2 x ACE 2
x ACE 2
ACE 3 ACE 3
ACE 3
ACEx5ACE 5
x ACE 1
x ACE 1 x ACE 1
x ACE 1
x ACE 2 x ACE 2
x ACE 2
x ACE 3 x ACE 3
x ACE 3
ACE 4 ACE 4
ACE 4
ACEx5ACE 5
x ACE 1
x ACE 2
ACE 3
x ACE 5
x ACE 2
x ACE 3
ACE 4
x ACE 5
Removing an ACE from folder Y (or folder X) results in an ACE with isInherited = false for the given folder only –
without adding ACEs to its descendants, if enumACLSetType = object-only (or dont-care).
Removing an ACE from folder Y (or folder X) results in removal of the ACE from the folder, and if isInherited = true
also results in removal of this ACE from all of it’s descendants (document D for folder Y, folder Y and document D
for folder X), if enumACLSetType = propagated (or dont-care).
E.g. removing ACE2 to X (ACL provided to setACL is ACE1) results in ACE2 being removed from X for
enumSetACLType = object-only; in ACE2 being removed from X and inherently removed from Y and D for
enumSetACLType = propagate; in ACE2 being removed from X and a repository specific behavior for
enumSetACLType = dont-care:
object-only
folder Y
document D
ACL Proposal 0.4
propagate
ACE 1
ACE 1
ACE 1ACE 1
ACE 1
x ACE 1
x ACE 1
x ACE 1
x ACE 1
ACE 2
ACE 2
ACEx1X
ACE 1
x ACE 2
ACE 3
ACE 3
ACE 3ACE 3
ACE 3
ACE 3
x ACE 1
x ACE 1
x ACE 1
x ACE 1
x ACE 2
x ACE 2
ACEx1ACE 1
x ACE 2
x ACE 3
x ACE 3
x ACE 3
x ACE 3
ACE 4
ACE 4
ACE 4
ACEx3ACE 3
ACE 4ACE 4
ACE 1
folder X
dont-care
ACE 2
ACE 4
18
CHECKING PRIVILEGES
ObjectService.getAllowableAction would require more specification anyhow... (e.g. is currently unclear, what has
to be checked for a moveObject operation).
TBD: How to use getAllowableAction in detail?  CMIS specification.
CHANGES TO THE SPECIFICATION
[Pages relate to Version 0.51, PDF-Files]
In “Overview of CMIS 1.0”, the following should be added :
7. Beside Policies a CMIS repository has the option to provide Access Control Lists (ACLs) as well. to control access
to document and folder objects (ACLs can not be applied to relationships and policies).
PROPOSAL: General Concepts > Areas that are out of scope for CMIS 1.0 : Authorization : change
Old: CMIS provides no mechanism for an application to specify what operations a particular user should be able to
perform on a given Object in a Repository, via the CMIS interfaces or otherwise.
Although CMIS provides policies and ACLs to control access for CMIS objects as an optional feature, CMIS provides
no mechanism to specify policies itself.
ACL Proposal 0.4
19
REQUIRED PERMISSIONS PER OPERATION
OVERVIEW
The table below shows an overview for the proposed usage of the basic permissions per CMIS operation.
Operation
OBJECT SERVICE
Read
Create…
Write
All
parent
GetAllowableActions
GetProperties
object
GetContentStream
document
UpdateProperties
object
MoveObject
object,
parent,
target
DeleteObject
object
DeleteTree (delete)
object
DeleteTree (unfile)
document,
parent
SetContentStream
document
DeleteContentStream
document
REPOSITORY SERVICE
Read
Write
All
NAVIGATION SERVICE
Read
Write
All
GetDescendants
folder
GetChildren
folder
GetFolderParent
folder
GetObjectParents
object
GetCheckedoutDocuments
document
MULTIFILING SERVICE
Read
Write
All
GetRepositories
getRepositoryInfo
getTypes
getTypeDefinition
AddObjectToFolder
ACL Proposal 0.4
folder,
object
20
RemoveObjectFromFolder
folder,
object
DISCOVERY SERVICE
Read
Query
object
VERSIONING SERVICE
Read
Write
All
Write
All
checkOut
document
cancelCheckOut
document
checkIn
document
getAllVersions
document
RELATIONSHIP SERVICE
Read
Write
All
Read
Write
All
getRelationships
POLICY SERVICE
ApplyPolicy
RemovePolicy
GetAppliedPolicies
OBJECT SERVICE
CreateDocument Operation
If a parent folder is specified, Write permission is required on the parent folder.
TBD: What happens if no parent folder is specified? Possible solution: All unfiled documents have a virtual parent
which contains the access rights for unfiled documents.
CreateFolder Operation
Requires Write permission on the parent folder.
CreateRelationship Operation
TBD
ACL Proposal 0.4
21
CreatePolicy Operation
Requires Write permission on th specified object.
GetAllowableActions Operation
For this operation no specific permission is required.
GetProperties Operation
Requires Read permission for the specified object
GetContentStream Operation
Requires Read permission for the specified object
UpdateProperties Operation
Requires Write permission for the specified object
MoveObject Operation
Requires Write permission on the parent folder of the object to be moved, Write permission on the target folder
and Write permission on the object to be moved.
DeleteObject Operation
Requires All permission on the object to be deleted.
DeleteTree Operation
Depending on the specified parameters the operation can result in an unfiling or in a delete for several objects.
The required permissions are differ for unfiling or deletion:
ACL Proposal 0.4
22
Delete: For all objects to be deleted, All permission is required.
Unfile: For non folder objects to be unfiled, Write permission is required on the object itself and its parent.
SetContentStream Operation
Requires Write permission on the object to be updated.
DeleteContentStream Operation
Requires Write permission on the object to be updated.
REPOSITORY SERVICE
GetRepositories Operation
For this operation no specific permission is required.
getRepositoryInfo Operation
For this operation no specific permission is required.
getTypes Operation
For this operation no specific permission is required.
getTypeDefinition Operation
For this operation no specific permission is required.
ACL Proposal 0.4
23
NAVIGATION SERVICE
GetDescendants Operation
Requires Read permission on the specified folder. The method returns only those descendants where the user has
Read access to.
GetChildren Operation
Requires Read permission on the specified folder. The method returns only those children where the user has
Read access to.
GetFolderParent Operation
Requires Read permission on the specified folder and its parent. If the ancestor nodes are requested, the method
returns only those ancestors, where the user has Read permission to.
GetObjectParents Operation
Requires Read permission on the specified object. The method returns only those parents, where the user has
Read access to.
GetCheckedoutDocuments Operation
Requires Read permission for the checked out documents. The method returns only those checked out documents
where the user has Read permissions to.
MULTIFILING SERVICE
ACL Proposal 0.4
24
AddObjectToFolder Operation
Requires Write permission on the specified parent folder.
RemoveObjectFromFolder Operation
Requires Write permission on the specified parent folder and Write permission on the object to be removed.
DISCOVERY SERVICE
Query Operation
A query always returns only those objects where the user has Read permission to.
VERSIONING SERVICE
checkOut Operation
Requires Write permission on the specified Object
cancelCheckOut Operation
Requires Write permission on the specified Object
checkIn Operation
Requires Write permission on the specified Object
ACL Proposal 0.4
25
getAllVersions Operation
Requires Read permission on the specified Object
RELATIONSHIP SERVICE
getRelationships Operation
TBD
POLICY SERVICE
ApplyPolicy Operation
Requires All permission on the specified Object
RemovePolicy Operation
Requires All permission on the specified Object
GetAppliedPolicies Operation
Requires Read permission on the specified Object
ACL Proposal 0.4
26