jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marian Schedenig (qs)" <Marian.Schede...@qualysoft.com>
Subject Re: WebDAV and ACLs
Date Wed, 08 Apr 2009 10:23:00 GMT

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.


Mime
View raw message