IECM Security Discussion

Document created by resplin Employee on Jun 6, 2015
Version 1Show Document
  • View in full screen mode

Obsolete Pages{{Obsolete}}

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



IECM


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

Attachments

    Outcomes