Ok, this seems to be working rather well so far. I'm now using a DefaultSecurityManager and a DefaultAccessManager with a customised LoginModule (for password validation) and a custom PrincipalProvider (for LDAP access).
I've also extended the servlet to wrap all resources in a custom AclResource, which delegates to the original resource but takes care of providing WebDAV's ACL properties in addition to those of the original resource. For this, I've created several properties which evaluate their values lazily, so that I don't have to build the entire ACL property when it's not even requested by the client. These properties are also invisible in allprop requests, as recommended by the DAV spec. (I should not that evaluating all this stuff seems to take a lot of typecasts on faith, i.e. casting interfaces to their Jackrabbit implementation counterparts, so I expect to have some work to do when the next version comes out and some of this changes) So far, I've taken care of DAV:supported-privilege-set and DAV:acl. On the server side, I take the privileges from the privilege registry, convert most of them to their DAV counterparts (those that seem to be exact matches that is) and use a "JCR:" namespace for the rest of them. This ensures that the client sees the actual privileges used by the server. Setting these seems to have the desired effect on the server side. I'm now worrying about two things: 1) DAV:current-user-privilege-set should return the ACL for the current user, the idea apparently being that regardless of the user is allowed to read the resource's full ACL, he should at least have access to his own privileges. But as far as I understand, I need JCR_READ_ACCESS_CONTROL permission to read any part of the ACL. Does that mean that a user is either allowed to read the full ACL or nothing, not even his own privileges? 2) I'm also trying to support the DAV:owner property, denoting the owner of a resource. This will be a simple string property containing the principal's qualified name*. Querying it should therefore be simple. Setting it should be allowed either (1) only for the owner and the admins, or (2) alternatively be controlled through a custom privilege "modify-owner". As far as I can tell, I have to provide my own ACLProvider so I can take care of compiling different permissions when DAV:owner is accessed (I have to handle the SET_PROPERTY permission manually in the grants() method). Is this the correct way to to this, or am I getting myself in too much trouble because I missed a more simply way? Also, in case of (2), how would I go about creating and registering a custom privilege - obviously, I'd have to put it in the privilege registry, but where can I do that, and how would I make it an aggregated privilege of JCR_ALL? *) It's a bit of a hack, but for now I'm using the qualified LDAP name to identify principals. The DAV spec says principals "should" be referenced by a HTTP or HTTPS URL, and obviously this would allow any compliant DAV client to browse the users, but I don't see a way to mirror the LDAP directory into a JCR collection (certainly not within a short implementation time and with good performance), so I have my client access the LDAP on its own and just use the qualified names in DAV requests. Not portable for a generic implementation, but good enough for us, for now at least. (Next up, once this works, is versioning, which will probably mess up my AclResource delegate and cause some more work there, too) Thanks as always, Marian. -- View this message in context: http://www.nabble.com/WebDAV-and-ACLs-tp22287762p22947463.html Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
