Re: [cmis-comment] What should CMIS Producer do when Consumer does not have access to the folders between an object and the root folder?

[David Choy <david.choy500@gmail.com>]

Hi Brian,

Thank you for your question.

Repositories vary widely. It is by intention that the CMIS spec does not prescribe how the CMIS interface should be implemented. This is to allow each provider to design a suitable CMIS implementation for his particular repository so that the integrity of his system can be preserved, that information security is not compromised, and that his implementation can be simplified.

For your example, your native repository allows a user to access an object by query, by ID, or by path, but does not allow the user to access the folder(s) that contain this object. In this case, it is ok for an CMIS implementation to expose the path of an object to the user and allow the user to use the path to access the object, but does not allow the user to navigate the path (i.e. to access the intervening folders). In mostly cases, the path of an object is provided by the underlying repository (either stored or computed). But in your case, apparently your CMIS layer would construct a path by navigation using the user's credential. This would be a problem. One solution is to use a privileged credential to construct path, which may create quite a bit of complexity depending on your repository's connection/process model. A simpler solution would be just not returning a path for that object. The user could use Object ID to access the object instead. The "partial path" approach you suggested does not appear to be a generic solution. On the other hand, if a "partial path" can uniquely identify an object then wouldn't it be the equivalent of a "full path" after all?

Please note that the folder hierarchy exposed through CMIS does not need to follow the (underlying) native folder hierarchy, so long as the CMIS layer can perform proper translation. Therefore, a CMIS path for an object may not necessarily be the same as its native path. It is useful to expose a different hierarchy through CMIS if, for example, leaking the names (and the relationships) of confidential intervening folders through CMIS object path is a security breach for a system. A different hierarchy that does not reveal confidential folders could be exposed through CMIS instead. Another approach to mitigate your problem is to expose such objects  (to users who cannot navigate to them) as "unfiled" CMIS objects, which simply do not have a path.

Cheers.

David

On Wed, Sep 26, 2012 at 12:43 PM, Inouye, Brian <Brian.Inouye@xerox.com> wrote:

Hi,

 

I have a question about the cmis:path property.  I am implementing a CMIS Producer and need to dynamically generate the cmis:path property when it’s requested since it’s not a stored property.  This is not a problem unless the calling Consumer does not have access to one or more of the intervening folders between an object and the root folder.  My repository allows this because each folder and document object has its own ACL.  Obviously, the Consumer would not be able to get to the object through navigation, but the object could be found through the CMIS query method.  If the Consumer (user) does not have access to an intervening folder, I am unable to generate the path to root.

 

Both the 1.0 Standard and the 1.1 draft do not say anything about this issue.  Nor can I find anything that says how the path is used other than it can be passed to the getObjectByPath service.  I’m wondering if in the case above, I can just omit any folders from the path that the user cannot access, as long as my implementation of the getObjectByPath service will accept that “partial path” and successfully return the object.

 

It seems the CMIS Standard does not discuss this issue in general where a user may not have access to an object’s parent (or some other object along the parental path).

 

… Brian …