Hi Dirk, o.k., I had a look into the ACL standard and you are right, a principal has to be a webdav resource and so in slide we will need the userpath. My example/trick with changing the userpath should just demonstrate that it is possible to change the access rights without having write-acl permission. But however the webdav (slide) admin has to spend special care to the Domain.xml file for protecting it against unauthorized userpath manipulation.
I had problems with your 'more flexible configuration' example. I didn't get it to run. Is it a planned or implemented feature? I think the standard says something about how to manage groups (principal collections) and principals. In case of a principal the DAV:resourcetype property should report DAV:principal. A collection principal should report DAV:principal and DAV:collection. regards Eckehard -----Original Message----- From: Dirk Verbeeck [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 22, 2002 11:03 PM To: 'Slide Developers List' Cc: Hermann, Eckehard; Pill, Juergen Subject: Re: userpath in ACL (original posting in Slide User) Hi Eckehard, My point is that the external principal href should be a real href and there is a difference between this path, the slide path and the store path. An overview of the current situation: ====================================================== context = webapp path servlet scope = scope parameter in web.xml, default "" store scope = scope parameter in domain.xml (store dependent), default "/" users path = users path in domain.xml A normal uri: External path /slide/files/document.doc Slide path (remove context & servlet scope) /files/document.doc Store path (remove store scope) /files/document.doc Example with servlet scope "/files" and a store mapped to scope "/storeA" External path /slide/files/storeA/document.doc Slide path (remove context & servlet scope) /storeA/document.doc Store path (remove store scope) /document.doc A principal uri (in acl or propfind request) Original path /slide/users/john Slide path (remove context) /users/john Store path (1) /users/john A principal from authentication Principal slide token john Slide path (add users path) /users/john (Code in SecurityImpl:getPrincipal but I think it should be more towards the servlet layer because it is a part of mapping your external Principal object onto a slide path) ====================================================== Internally Slide uses a slide path for all operations/lookups. Towards the web and towards the stores the slide path is manipulated. The only thing that is missing is what I explained in my previous mail, the mapping from a store principal to a slide principal (1). If the "users" store is the same as the "files" store then we want the current situation. <scope match="/" store="jdbc" userspath="/" /> The acl store path is /users/john on /files/document.doc. But with this more flexible configuration: <scope match="/" store="memory" userspath="/users" /> <scope match="/files" store="jdbc" userspath="/users" /> <scope match="/users" store="JNDI" userspath="/users" /> The acl store paths are john on document.doc The JDBC store has a rule for "john" on "document.doc" and slide knows where "john" is defined (userspath from line 2). With this configuration you can move the store scope without manipulating the uris. If your realm returns the domain together with the username, use something like /users/myserver/tom as a slide principal path. <scope match="/" store="memory" userspath="/" /> <scope match="/files" store="jdbc" userspath="/users/myserver" /> <scope match="/users/myserver" store="OS-store" userspath="/users/myserver" /> You define that the jdbc store acl rule with user "tom" is the user as defined in "/users/myserver/tom" If you later get another "tom" in another user store (another NT domain) then you add: <scope match="/files2" store="jdbc" userspath="/users/myserver2" /> <scope match="/users/myserver2" store="OS-store" userspath="/users/myserver2" /> and a store that needs to know about both: (the internal user is then "myserver/tom") <scope match="/files2" store="jdbc" userspath="/users" /> Your trick with changing the userpath is not a real-life example, in real-life you would create a group "editors" and add "tom" to the group when he needs write permission. I'm not sure what to do with groups, are the also mapped under /users or under /groups. Another issue is that currently a group acl principal needs a '+' sign in front of it, should that be removed or not? I thinking of keeping it to indicate to the store the parameter is not a user but a group. All of this is rather complex, mapping multiple stores into the same namespace but that is part of the slide architecture. Regards Dirk "Hermann, Eckehard" wrote: > > Hi Dirk, > > for authentication we would like to use as user-database the current OS, so > we wrote a Tomcat realm that does an authentication against the current OS > platform. Because of slide uses its one user-database for authorisation > (defined by the userpath) the user that is authenticated by Tomcat differes > from the user used for the authorisation by slide. For example we have a > user 'tom' with a password 'cat' that is authenticated against the NT domain > 'myserver'. For the authorisation the user tom will get the userpath prefix > myserver/acl/users, defined by the slide domain.xml file. For a file > testfolder/doc.xml two ACEs are defined one for the user > myserver/acl/users/tom with the right deny read and one for the user > testserver/acl/users/tom with the right grant read. For changing the right > of user tom from deny read to grant read I don't need to have the write-acl > right on the node testfolder/doc.xml, I just must be able to update the > userpath in the domain.xml file. > > I would like to be able to define an ACE with a principal like it is passed > from the authentication part to the authorisation part of my webdav server > and not maipulated by adding a userpath on its way later, which could be > updated by a third party. Yes it is true, I can define a store where I > remove the userpath when I go to the store, but in this case I still have to > add the userpath during I define an ACE with the ACL method and after this > it seems for me that it is used for nothing as just for slide internal > usage, but if it is so, I don't understand why I have to see it in the ACL > and PropFind methods. Please correct me if I'm on the wrong way. > > regards Eckehard -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
