1 / 9

CMIS ACL-Proposal

CMIS ACL-Proposal. 26-28 Jan 2009. Motivation: Scenarios Policies: Recap ACL Concept Proposal: Discussion Topics. Scenarios. End-User Collaboration Scenario. Development: No permissions used (might be passed through, but not interpreted)

nanda
Download Presentation

CMIS ACL-Proposal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CMISACL-Proposal 26-28 Jan 2009

  2. Motivation: Scenarios • Policies: Recap • ACL Concept • Proposal: Discussion Topics

  3. Scenarios End-User Collaboration Scenario 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 CMIS Application CMIS Application permissions Documents

  4. Scenarios Background Tasks Development: Usage of Permissions is being coded into the application Runtime: Application per- missions permissions mappings? CMIS Application CMIS Application permissions Documents

  5. Recap CMIS Objects

  6. ACL Concept Policies

  7. ACL Concept Permissions ALL All WritePolicy Delete WRITE Write WriteProperty WriteContent File Unfile Version READ Read ReadProperty ReadContent ReadPolicy

  8. 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 ?

  9. Revised proposal outline • GetACLs() • A collection of ACEs that are: • (<Principal>, <Positive boolean right>, booleanisInherited) • 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)

More Related