CMIS ACL-PROPOSAL Jan 2009
Motivation: Scenarios Policies: Recap ACL Concept Proposal: Discussion Topics
Scenarios Documents Development: No permissions used (might be passed through, but not interpreted) Runtime: Admin or enduser knows the permissions, assigned by a user to the documents End-User Collaboration Scenario CMIS Application CMIS Application permissions
Scenarios Documents Development: Usage of Permissions is being coded into the application Runtime: Application Background Tasks CMIS Application CMIS Application permissions mappings? permissions per- missions
Recap CMIS Objects
ACL Concept Policies
READ WRITE ALL Read All Delete FileWriteProperty ReadPolicy ReadContent UnfileWriteContent Write WritePolicy ReadProperty Version Permissions ACL Concept
Discussion Topics Assumption: unified user base no user discovery, no mapping (within the scope of CMIS) ok ? Scenario: flexible mapping („level 1“) vs. known permissions („level 2“) ? Permissions (Level 2): extended permissions required vs. Read/Write/All ? Modelling of ACLs: Policies vs. Properties ? [if policies] entire ACL vs. individual ACEs as Policy ? Format for ACLs: XACML vs. XML vs. other format ? format for principals (plain ID vs. type info + ID) ? ACL Assignment: atomic action when creating an object vs. inheritance ? ACL Inheritance: on create vs. create + lifetime ?
Revised proposal outline GetACLs() A collection of ACEs that are: (,, boolean isInherited) DeleteACE() – or SET MUST fail is ACE isInherited AddACE() – or SET MUST fail is object is not securable or repository does not support setting ACLs. RepositoryInfo: ACLSupportLevel: None, Get, Set Object Type definition includes: isSecurable Note: This proposal models ACLs as separate from policies (likely as a service on objects) Open questions: Need to make sure that there’s a way to express that a system has ACLs per-container and not per-document. Can we now delete Policies from the spec entirely? Is the permission set extensible or fixed? What rights do you need to get or set ACLs? Can we leverage the XACML standard for this capability? (Seems like no, so far) Need to make sure that we’re leveraging the knowledge/best practices? Why do we think we’ll succeed with an ACL approach (vs. policies) when iECM/JCR have gone the other way? Need to make sure that we’ve covered the basic collaborative cases (e.g. team sites, wikis, “my” content)… Out-of-scope: Repository offers no guarantee that the ACL list is complete (E.g. we won’t expose DENY rights, etc.) There’s no explicit statement about how to compute effective permissions for a user from the ACL (e.g. how inheritance/precedence of ACLs works)