I like the idea of keeping the model simple and easy. Focus
shouldn't be to cover every aspect and use case but to have something usable
for the most common cases. If we see the need to cover more complex use cases
we can enhance the scheme later.
A key aspect for me is to find a model flexible enough to be mapped
to the existing different implementations today in the repositories. We should preserve
the idea of CMIS being an interface to something what is already there instead
of something that needs to be implemented from scratch. We need to investigate
which level of "sharpness" we need to define as part of the model and
where we better live with making it implementation-dependent and/or discoverable.
And ACL should only be one form of a more general concept of authorization
services. Others dealing with different concepts than ACLs should be treated
equally in (hopefully) later versions of the spec.
Jens
From: Al Brown
[mailto:albertcbrown@us.ibm.com]
Sent: Montag, 24. November 2008 20:20
To: dennis.hamilton@acm.org
Cc: CMIS TC List
Subject: Re: [cmis] ACL Considerations and Concerns
Great start. Some comments on your points:
1. Agreed, however, providing directory services (user/group
discovery/expansion) should be kept to the bare minimum
3. I would suggest ignoring inheritance and make inheritance repository
specific or leverage the policy infrastructure
6. There is already a model in CMIS for exposing allowable actions you have on
an object. If repositories can expose those actions (rights), they should be
able to map them in reverse.
Some other comments:
1. XACML would be nice to leverage. However, I can't find a good mapping of ACL
to XACML. This one from IBM research http://domino.watson.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/3a2fb67c29bf0f21852574ac00404e82?OpenDocument&Highlight=0,karjoth.
I would suggest we discuss with that TC, but if it is not simple and straightforward,
leverage a different model
2. The proposal should be simple to understand, implement and use
3. The proposal should specify the minimum feature set
4. The DAV and JCR ACL model should be leveraged as input
-Al
Al Brown
ECM CTO Staff, Information Managament
Office 714 327 3453
Mobile 714 263 6441
Email albertcbrown@us.ibm.com
CONFIDENTIAL NOTICE: The contents of this message, including any attachments,
are confidential and are intended solely for the use of the person or entity to
whom the message was addressed. If you are not the intended recipient of this
message, please be advised that any dissemination, distribution, or use of the
contents of this message is strictly prohibited. If you received this message
in error, please notify the sender. Please also permanently delete all copies
of the original message and any attached documentation.
"Dennis E. Hamilton" ---11/24/2008 10:00:03
AM---I just wanted to put down some flags on where there may be hazards in
consideration of ACLs.
|
|
|
|
|
|
|
|
|
|
|
|
I just wanted to put down some flags on
where there may be hazards in consideration of ACLs.
(Julian Reschke can also offer experience on the ACL work for WebDAV.)
1. Identifying principles that are the subjects of authorization is
important. It is also a challenge. One might want an extensible
mechanism even though the kind of principle might be highly-restricted in order
to grab the low-hanging fruit.
2. Groups and group memberships are a problem.
3. Inheritance based on location context of a resource is a problem,
especially when there can be inter-mingled groups and atomic principles and
role notions.
4. The ability to specify exclusions creates complications for all of the
above.
5. Wanting an interoperable mechanism that is neutral with regard to
specific CMS repositories probably makes this an over-constrained problem.
So then the issue is how much pass-through is defined without actually
determining the end-point rules.
6. Considering 1-5, agreeing on the access and manipulations that are
authorizable (or restrictable) seems easy. It will also raise concerns
with respect to (5) and being able to build generic clients (e.g., an Explorer
model).
- Dennis
PS: I am not arguing against addressing this problem, because it does
matter in key use cases. The trick is going to find a simple set that
doesn't hurt later and doesn't impede having interoperable/generic
intermediaries that work well end-to-end.
Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability
mailto:Dennis.Hamilton@acm.org |
gsm:+1-206.779.9430
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php