IECM Security Discussion

[resplin]

Obsolete Pages{{Obsolete}}

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

IECM

Table of Contents

• 1 Identify capabilities


• 2 Types of permissions


• 3 Assign permission / capability to a principal


• 4 Assign a list of policies to attach


• 5 ACLs


• 6 Role-based


• 7 Life-cycle controlled

Identify capabilities

• For identified user - super-user capability?
  
• For current user
  

Types of permissions

• Grant / revoke
  
• Abstract policies
  
• Time-based policy-based control
  
• Role-based control
  
• Access Control Lists
  
• Records / Lifecycle control
  

Assign permission / capability to a principal

• Use Cases
  
  • I want to give my boss permission to read
    
  • I want my group to be able to update
    
  • I want an ad hoc team to be able to update
    
  • I want to give myself delete privilege
    

• Present a list of permissions
  

• Application can interrogate how to set permissions on a content object for the following basic, assumable list:
  
  • None
    
  • Read properties
    
  • Read content
    
  • Update
    
  • Delete
    
  • Versioning?
    
  • Association?
    

• Underlying system will provide the appropriate set of permissions or state that it cannot be done
  

• Most common scenario is: None, Read-only (properties and content), Edit (Update, Delete, Versioning, Associate...)
  

• Identify a list of principals - Query against LDAP / JNDI interface
  

• Grant / Revoke permission
  

• What could go wrong?
  
  • DCTM / eRoom - assumes update (different from delete) apply - either too much permission or not enough.
    
  • Permission could subvert intended permission - How?
    
  • Can this override a hold?
    
  • Can this have unintended side-effects? Give someone permission that did not have anyway of setting?
    
  • Application / User could assume that permission is granted, but it is not - Should / Can the underlying system inform the user through exception?
    
  • To grant / revoke permission on all items in a folder or a group of documents would require N (number of documents) X M (number of people assigned) X P (permissions per document) calls
    

• Assumptions
  
  • This will go through each CMS implementation�s APIs
    
  • This API will throw an exception if it doesn�t work
    

Assign a list of policies to attach

• Use Cases
  
  • Assign predefined ACLs to a single content object
    
  • Records management assign update policies
    
  • Collaborative environment - assign team permissions (team must be pre-defined)
    
  • Role-based security ability to assign role types to content operations
    

• There may be more than one logical default for a user
  
  • JSR-170 failed to provide a suitable security model by just using a single system default
    

• Do not assume anything about the policy, just give a user readable name or description
  

• Could be encapsulating one of the following:
  
  • ACL
    
  • Role-based capability - update only for authors
    
  • Records-control - file plan (overloading permissions?)
    
  • A logical packaging of capabilities
    

• For each content the system should:
  
  • Associate a policy to a content object or folder or any other entity exposed by iECM
    
  • Provide a list of policies that can be associated with a content object
    
  • List of policies for current user (and any named user?)
    
  • User chooses one (or more?)
    
  • If operation fails, an exception is thrown
    
  • Is there an argument to this interface? Principal?
    

• Is this functionally equivalent to the previous grant / revoke?
  
  • Depends on whether this has two arguments for policy -- a policy and to whom it should apply
    
  • Policies can then be permissions or ACLS?
    
  • A bit like applyPolicy(object,...) where arguments can be anything
    

• What can go wrong?
  
  • Can this subvert the underlying permission mechanism -- Unlikely since the choices are being presented by the underlying system
    
  • If the mechanism is applied, will the user assume that they have more permissions than specified -- same as before
    
  • There is no way to define the policy, but this is intentional
    
  • This cannot replace the previous proposal, since there is no explicit way to 'allow my boss to read' -- an ACL or policy will need to be created that includes the boss
    
  • What capabilities can an application developer assume? In the case of *no* end user, how does one decide a choice?
    
  • Are there some basic assumptions that application developers want to assume?
    
  • How and what context do you provide the underlying system?
    

ACLs

• Use Case
  
  • Allow an ad hoc group of people to collaborate on a space
    
  • Remove burden of defining a group or ACL from the system administrator
    
  • Provide a mechanism to associate an ACL or group to items in that space
    
  • Easily add or remove a member to permissions on the items in the space
    

• What can go wrong?
  
  • Inheritance of permissions cannot be assumed by the application
    
  • Permissions can subvert the underlying mechanism -- an unintended interpretation of ACL
    
  • Can unintended overriding be prevented?
    
  • What additional value is there over the previous proposal? -- Ad hoc set up of permissions
    

• Assumption
  
  • ACL - System that
    

Role-based

Life-cycle controlled

• Update / Deletion controlled through external means
  
• Hold
  
• No update