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 -----Original Message----- From: Dirk Verbeeck [mailto:[EMAIL PROTECTED]] Sent: Monday, January 21, 2002 10:54 PM To: Slide Developers List; Hermann, Eckehard Subject: Re: userpath in ACL (original posting in Slide User) Hi I don't agree that "contextpath + userpath + user" isn't webdav conform. When I look at webdav acl draft 06 spec 5.4.5 Example: Retrieving a Resource's Access Control List I see the following response example: <D:principal> <D:href> http://www.webdav.org/_acl/groups/maintainers/ </D:href> </D:principal> The principal href should be a full uri for the principal resource. Slide has a restriction that all principal resources must be under <userspath> I thought about removing this restriction but decided against it. It is actually the <D:principal-collection-set> definition. You can enhance this to a list of principal collection sets. One thing you might want to change is to define a userspath for each store and remove this path from href going to the store. For example: The principal /users/john is now stored in the security store as /users/john We can't remap the stores because the full slide uri is in the security store. The enhancement would be to define: <scope match="/" store="jdbc" userspath="/users" /> When the store with john gets remapped to /users/mydomain/john you can change the scope to: <scope match="/" store="jdbc" userspath="/users/mydomain" /> this way you don't have to update the acl's and you can restrict/define the users that are know to the acl's in this scope. The external view of this uri is then http://host:port/context/users/mydomain/john And that is the purpose of the domain file to map stores to a webdav uri space. Back to your point, why do you want to remove userspath from the external uri ? Dirk "Hermann, Eckehard" wrote: > > Hi Dirk, > > currently it is so, if you define an ACE, the principal has to consist of > the userpath + user. If you do a propfind acl, the principals of the ACEs > also consist of the contextpath + userpath + user. This seems for me slide > specific and not webdav conform. So I would like to change the > parsePrincipal() method of the ACLMethod as follow (see bold typed): > > protected String parsePrincipal(Element principal) throws > WebdavException { > > // FIXME: make constants and make sure they are used in > // AclMethod:parsePrincipal and PropFindMethod:writePrincipal > NodeList hrefList = > principal.getElementsByTagNameNS(NodeProperty.DEFAULT_NAMESPACE, "href"); > if (hrefList.getLength() == 1) { > Element href = (Element) hrefList.item(0); > if (href.getFirstChild().getNodeType() == > Node.TEXT_NODE){ > if > (token.getNamespaceConfig().getUsersPath() != null) { > return > (token.getNamespaceConfig().getUsersPath() + "/" + > getSlidePath(href.getFirstChild().getNodeValue())); > } else { > return > getSlidePath(href.getFirstChild().getNodeValue()); > } > } > } else if (hasChild(principal, NodeProperty.DEFAULT_NAMESPACE, > "all")) { > return "nobody"; > } else if (hasChild(principal, NodeProperty.DEFAULT_NAMESPACE, > "self")) { > return "~"; > } else if (hasChild(principal, NodeProperty.DEFAULT_NAMESPACE, > "unauthenticated")) { > return token.getNamespaceConfig().getUsersPath() + "/" + > token.getNamespaceConfig().getGuestPath(); > } > throw new WebdavException(WebdavStatus.SC_BAD_REQUEST); > } > > and the writePrincipal() method of the PropFind Method: > > protected void writePrincipal(XMLPrinter generatedXML, String principal) > { > generatedXML.writeElement(null, PRINCIPAL, XMLPrinter.OPENING); > // FIXME: Apparently, there are or will be some other cases, but it > // isn't very clear in the spec > > // remove userpath, if available > if > (principal.startsWith(token.getNamespaceConfig().getUsersPath())){ > if (principal.length() == > (token.getNamespaceConfig(). > > getUsersPath()).length()) { > principal = "nobody"; > } else { > principal = > principal.substring((token.getNamespaceConfig(). > > getUsersPath() + "/").length()); > } > } > > if (principal.equals("~")) { > generatedXML.writeElement(null, "self", XMLPrinter.NO_CONTENT); > } else if (principal.equals("nobody")) { > generatedXML.writeElement(null, "all", > XMLPrinter.NO_CONTENT); > } else { > generatedXML.writeElement(null, "href", XMLPrinter.OPENING); > generatedXML.writeText(principal); > // generatedXML.writeText(getFullPath(principal)); > generatedXML.writeElement(null, "href", XMLPrinter.CLOSING); > } > generatedXML.writeElement(null, PRINCIPAL, XMLPrinter.CLOSING); > } > > Now just the user without any path-prefix has to be passed with the ACL > method or will be returned by the PropFind method. What do you think about > it and do you remember of any further parts that have to be changed in this > context as well? > > regards > > Eckehard > > Eckehard Hermann > Research & Development > Software AG > Uhlandstrasse 12 > D-64297 Darmstadt > Germany > > mailto:[EMAIL PROTECTED] > phone: +49-6151-921465 > fax: +49-6151-921609 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
