The official documentation is at: http://docs.alfresco.com
- 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:
- Read properties
- Read content
- 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
- 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:
- 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?
- 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
- Update / Deletion controlled through external means
- No update