RE: Next conf call for ACL proposal

[Choy_David@emc.com]

Based on today's discussion, it appeared that there are four areas in the access control proposal that need clarification or fine-tuning.
Below are a few thoughts on each.

1. Inheritance
A normative description of inheritance is needed, in addition to examples. The following is my understanding of the proposal. See if it is correct.
- Each object can have at most one ACL, which may be one that is explicitly defined for this object (by specifying one ACE at a time) or an inherited ACL, but not both.
- The granularity of inheritance is an entire ACL, even though each ACE has its own inheritance setting. Can the separate ACEs of an ACL have different inheritance setting? If so, what would it mean?
- An inheritance path is either via a folder relationship or transparent to user (i.e. unknown through CMIS). Only folder-inheritance can be defined through CMIS. In that case, inheritance is defined at the source node (the folder where ACL is created), not at the target node (a recipient), and inheritance propagates all the way to the leaves of the folder subtree. An object in this subtree can not "opt out" of the inherited ACL.
- If more than one parent of a document has a "inheriting" ACL, what is the ACL for this multi-filed document?
- Is there a use case for *creating* folder-based ACL inheritance through CMIS? Do we have a reasonable fix for the above issues without imposing unnecessary restriction? Will it be sufficient to have transparent inheritance only for v1.0? Removing folder-based inheritance can simplify the proposal.

2. ACL sharing
The current proposal treated ACL as an integral part of an object. As such, it disallowed ACL-sharing between objects. The main reason for this approach was because some repositories do not support ACL-sharing.
On the other hand, there are use cases (esp. LoB apps) where ACL sharing is needed either because of a high-volume ingestion scenario or because of a need for a single ACL change to affect many controlled objects. The policy object in the current spec was created with such policy-sharing in mind. Treating policy as a standalone object also simplifies query on policy objects should there be a need for it. Nevertheless, it is not a requirement that policy object be used for access control.
It is indeed a stated v1.0 goal to accommodate existing repositories. It is not a goal, however, to limit CMIS to existing technologies only, and therefore we should avoid imposing broad restriction unless it is necessary.
It appears that if we treat ACL more generically as a standalone object, it shouldn't be a problem for any repository to create an object to hold an ACL. When an ACL object is "applied" to a to-be-controlled object, a repository can choose (as an implementation) to copy the stored ACL to the controlled object. A repository that does not support shared ACL can disallow an ACL to be applied to a second controlled object. Or, alternatively, if an ACL object is applied to multiple objects, then it can not be updated. Either of these can be an allowable implementation constraint if we take a more generic approach. Will this work?

3. Policy object
If policy object is not used for access control, then whether it should remain in the v1.0 spec becomes an issue by itself. The policy object in the current spec is primarily a place holder in anticipation of supporting specific form(s) of policy. To make it useful, specific semantics need to be defined for specific type(s) of policy objects. If policy object merely serves as a passive container for repository-specific policy, then it has no value. One can use a document object to store a policy and a relationship object to link it to an object controlled by this policy. If we intend to define the semantics later on, then we should introduce the whole thing when we are ready. There is very little to gain by committing to a design in advance, even if the design is seemingly the right choice when we need it.

4. Principal ID
An access control proposal has to bind permission and object to principal in one way or another. Therefore a way to identify a principal is a necessity. However, modeling of principal, and identity management in general, is system-specific and difficult to standardize. Currently, the management of principal is considered out of scope. In the current proposal, a principal ID is an opaque string which is assumed to identify a principal that is known to the repository. This appears to be the simplest way to define an interoperable access control mechanism. However, there are still identity management issues to be addressed, such as:
- How does an app find the correct principal id that is to be used in an ACE? If the app needs to talk to the repository natively to find principal id, then should it create ACL natively as well? If CMIS is to provide a method for app to find principal ids, then we are back to identity modeling: What attributes of a principal are maintained? What kind of search is allowed? Etc.
- If a third-party identity manager is used, how does a principal id link to the third-party registry?
- Phantom principal problem: Can an ACE contain a principal id that has not been defined yet or that has already been deleted? Shall we consider this merely an implementation issue?

Hope these help follow-on discussions.

david

-----Original Message-----
From: David Pitfield [mailto:david.pitfield@oracle.com] 
Sent: Monday, March 23, 2009 11:11 AM
To: Goetz, Paul
Cc: Gavrysh, Viktor; Florian Müller; Jens Hübel; Hermes, Martin; Klevenz, Stephan; ryan.mcveigh@oracle.com; Choy, David; Nicolas Pombourcq
Subject: Re: Next conf call for ACL proposal

Hi Paul -

Unfortunately I have a schedule conflict.  However I have sent my 
questions and comments on the current draft to Nicolas, who will try to 
attend tomorrow.

Nicolas and I are further discussing the proposal with our Oracle 
colleagues, and based on this, will post some more detailed comments 
back to the TC by the end of the week.

Regards.
dbp

Goetz, Paul wrote:
>
> When: Dienstag, 24. März 2009 17:00-18:00 (GMT+01:00) Amsterdam, 
> Berlin, Bern, Rome, Stockholm, Vienna.
>
> Where: ConfCall (code 429189)
>
> *~*~*~*~*~*~*~*~*~*
>
> Hi,
>
> Viktor provided a first draft for the SOAP bindings, so let's have a 
> discussion about it.
>
> Dial in numbers can be found here: 
> _https://www.sap-conferencing.com/conference/html/DialIn_No.html?productId=-1_.
>
> US:* +1 215 303 4494* or* +1 212 444 0504*.
>
> Germany:* +49 69 210 869 100*.
>
> Dial in code is* 429189*.
>
> Best regards,
>
> Paul
>