Hello Peter, IMHO the slide store interface did not provide guaranteed ordering to the ACEs in an ACL.
does the new security implementation still have this problem? Regards, Marc Am Mit, 2003-11-05 um 16.59 schrieb Nevermann, Dr., Peter: > Hi Slide Users, > > I would like to let you know, that we made an effort to get the server-side > security implementation compliant to draft-12 of the WebDAV/ACL standard. As > you probably know, it was conforming to draft-7 (if at all) ... which is > becoming a bit outdated. > > My apologies for any inconveniences this changes may cause at your side. As > a precaution, I created a CVS tag "SLIDE_2_0_1" to freeze the "old" security > implementation. > > Please find draft-12 of the WebDAV/ACL spec at: > http://webdav.org/acl/protocol/draft-ietf-webdav-acl-12.htm > > > Remarks on the new implementation: > > 1) Please check-out the modified Domain.xml file from src/conf/webapp. The > way principals, actions and permissions are initialized changed. Also the > mapping of the Slide actions to the action nodes changed in the namespace > config. > > > 2) The new ACL-evaluation implementation is in > org.apache.slide.security.ACLSecurityImpl and is now loaded by default. Old > implementations (SecurityImpl or SecurityImplAllGrant) can still be > activated through the "acl_semantics" parameter in the namespace config ... > but, be warned, I didn't test it and it is very probable that adaptations > are needed in the old implementations. > > > 3) Principals (users, groups/roles) continue to be represented as resources > in the namespace (required by the spec, BTW). There are parameters > "userspath", "groupspath" and "rolespath" in the namespace config to define > the locations of principals. > > There is no substantial difference between "group" and "role" here ... > unless the utilized user DB makes a difference. So, normally it should be > enough to configure *either* the groupspath *or* the rolespath. The spec > only talkes about a "group" as principal representing a set of other > principals. > > NOTE: the new ACL-evaluation implementation does not yet support groups in > groups ... this is still a TODO :-) > > User & group/role relationships are not be mapped anymore to the URI > hierarchy, i.e. if a user /users/U is a member of group /groups/G, there is > *no* URI /groups/G/U representing the user. Instead, new properties of the > principal resources are used: DAV:group-member-set and DAV:group-membership. > This allows for many-to-many relationships between users and groups/roles. > > BTW, do we still need the "old" role concept-&-implementation existing in > Slide??? Comments, please. > > > 4) Actions (called privileges in the spec) continue to be represented as > resources in the namespace. There is a parameter "actionspath" in the > namespace config to define the location of actions. > > New properties of the action resources, DAV:privilege-member-set and > DAV:privilege-membership, are used to manage the aggregation relationship > between actions. [NOTE: these two props do not appear in the specs, because > the spec does not require actions to be WebDAV resources.] > > > 5) There are generic SubjectNode's [ALL, AUTHENTICATED, UNAUTHENTICATED, > SELF, OWNER] to be used in ACE definitions, which do not exist as real > principals in the namespace or user DB. Their URIs are "all" > "authenticated", ... respectively. In particular, the URI /users *doesn't* > anymore represent "all" users. > > > 6) There is a generic ActionNode ALL to be used in ACE definitions, which > does not exist in the namespace. Its URI is "all". In particular, the node > /actions doesn't anymore represent "all" actions. > > > 7) During server start-up, the active user is UNAUTHENTICATED and all Slide > action are temporarily mapped to a generic DEFAULT action which passes all > security and lock checks. So, the user DB as well as the Lock and Security > stores are not accessed anymore during start-up. > > Regards, > Peter -- Marc Sommer I::Dev +49 721 91374-364 Schlund + Partner AG PGP Key-ID: 0743ED19 http://www.schlund.de
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
