You mean an index in memory? That's what I did for matching in the actions hierarchy, because the total number of actions is retricted to some 20 or so. But I discarded it for the the principals hierarchy (better: principals net).
How do DASL (you mean the implementation in Slide?) and Lucene do with an index? Regards, Peter > -----Original Message----- > From: Mike Oliver [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 06, 2004 14:37 > To: Slide Users Mailing List > Subject: Re: Security implementation: ACL draft-12 compliance > > > If the problem is matching with nested groups, would it make sense to > borrow from DASL or Lucene and create an index of these trees so a > "match" can be done in one "search"? > > Ollie > > > Nevermann, Dr., Peter wrote: > > >>Is this a priority for the 2.0 release? > >> > >> > > > >Yes, I think so. > > > >As I said before: > >I put that aside because I didn't find an efficient way to evaluate > >principal matching with nested groups of arbitrary depth (one have to > >navigate the DAV:group-membership association to the end to > assert that it > >wasn't a match :-(). > >Maybe there should be a maxDepth parameter (e.g. in > NamespaceConfig) for > >group nesting? Other ideas? Comments? > > > >Regards, > >Peter > > > > > > > >>-----Original Message----- > >>From: Jacob Lund [mailto:[EMAIL PROTECTED] > >>Sent: Tuesday, January 06, 2004 10:10 > >>To: 'Slide Users Mailing List' > >>Subject: RE: Security implementation: ACL draft-12 compliance > >> > >> > >> > >> > >>>NOTE: the new ACL-evaluation implementation does not yet > >>> > >>> > >>support groups in > >> > >> > >>>groups ... this is still a TODO :-) > >>> > >>> > >>Is this a priority for the 2.0 release? > >> > >>/Jacob > >> > >>-----Original Message----- > >>From: Nevermann, Dr., Peter [mailto:[EMAIL PROTECTED] > >>Sent: 5. november 2003 17:00 > >>To: 'Slide Users Mailing List' > >>Subject: Security implementation: ACL draft-12 compliance > >> > >>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 > >> > >> > >>------------------------------------------------------------ > --------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
