Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of anchela@day.com designates
 207.126.148.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <22308954.post@talk.nabble.com>
References: <22287762.post@talk.nabble.com>
	 <bfeaddf70903020709v11b92b74lf6e4e5ca71c8df35@mail.gmail.com>
	 <22308954.post@talk.nabble.com>
Date: Tue, 3 Mar 2009 16:14:37 +0100
Message-ID: <bfeaddf70903030714o260d6965geec82b40fb85667@mail.gmail.com>
Subject: Re: WebDAV and ACLs
From: Angela Schreiber <anchela@day.com>
To: users@jackrabbit.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

> I've written a basic PrincipalProvider that wraps around my LDAP access
> layer. I can't figure out how to configure Jackrabbit to use this provider
> though.

as part of the LoginModuleConfig

> I assume I also need a custom login module (as the principal provider
> possibly can't work without valid credentials, and because I need to specify
> how to authenticate a user anyway).

how login credentials are mapped to a principal is not defined by
the AbstractLoginModule. the default implementation make use of
the UserManager (see DefaultLoginModule#getPrincipal).
the AbstractLoginModule uses the principal provider to retrieve all
principals that will be present with the subject created upon login.
those are used to - later on - evaluate the permission of the user/session.

> Once these two are in place, can I
> simply rely on the default principal, access and security managers to use
> the ACL privileges already provided by Jackrabbit?

i'm not sure if i understand what you mean by "use the ACL privileges
provide"...
authentication is just one side and isn't part of the jsr 170/283 specification.
authorization on the other hand is - to a certain extend - defined by
jsr 283 through the means of
an AccessControlManager that allows to view, set, remove access
control policies.
which policies can be applied depends on the implementation. and so is
the nature
of the policies. for simplicity jsr283 defines a policy sub-interface
AccessControlList.
if an implementation chooses to support ACL-policies, the API user is
enabled to modify the
privileges for a specific principal on a specific node by creating
access control
entries. otherwise (no ACLs supported) permission can only be changed
by modifying
the policies present on a node.

> When all of this works, I suppose I just have to change my WebDAV handler
> extensions to access Jackrabbit's ACLs through an ACLProvider instead of
> accessing my own custom nodes.

you should access the access control policies through the AccessControlManager.

after all i'd say the prefered way would be to make your webdav
resource implement
the org.apache.jackrabbit.webdav.security.AclResource and let the
implementation
act on the AccessControlManager. but that's just my feeling... i
didn't check whether
it's feasible.

regards
angela