hi brian,
i ran into a similar problem.
my setup was:
- webapp 1 running a jackrabbit repository(A)
- webapp 2 running a jackrabbit repository(B) which i registered using jndi
(both repository use the SimpleAccessManager)
when i tried to access the repository B in webapp 1 via jndi i ran
into similar problems with the authentication stuff as you described
above.
this solution worked for me:
i moved following class files from the "jackrabbit.jar" into a newly
created jar-file (e.g. jackrabbit-security.jar):
- org\apache\jackrabbit\core\security\AnonymousPrincipal.class
- org\apache\jackrabbit\core\security\CredentialsCallback.class
- org\apache\jackrabbit\core\security\CredentialsCallbackHandler.class
- org\apache\jackrabbit\core\security\SimpleLoginModule.class
- org\apache\jackrabbit\core\security\SystemPrincipal.class
- org\apache\jackrabbit\core\security\UserPrincipal.class
i put this jar-file in the $JETTY_HOME/ext folder (for jetty). (in
your case $CATALINA_HOME/common/lib).
it than worked fine. i could not find a more elegant way to solve this
problem so far. i am not sure if the use case helps to solve your
problem...
regards,
philipp
On Tue, 29 Mar 2005 12:55:21 -0800, Brian Moseley <[EMAIL PROTECTED]> wrote:
> i've written a custom implementation of AccessManager to provide my own
> rules for permission checking in my JCR-based WebDAV server. i'm having
> a very frustrating problem with regard to
> casting/classloading/something. here's what's happening:
>
> 1) before there's any JCR interaction, Acegi Security authenticates the
> request and places an Authentication object (an interface that extends
> Principal) into a ThreadLocal.
>
> 2) my DavSessionProvider grabs the Authentication from
> the ThreadLocal and uses it to construct an instance of
> SimpleCredentials, which it then passes to Repository.login().
>
> ** i'd love to reimplement step 2 to pass null credentials, but in order
> to do that i'd have to get a Subject into the current
> AccessControlContext, and even after reviewing the JAAS Authorization
> tutorial, i'm at a loss as to how to do that.
>
> 3) my custom LoginModule ignores the passed in CallbackHandler (and the
> associated Credentials) and grabs the Authentication out of the
> ThreadLocal again, setting it as a principal on the Subject.
>
> ** as you can see, JAAS is totally superfluous to my security
> implementation and really just gets in the way :)
>
> 4) my AccessManager digs through the Subject's principals to find the
> Authentication, which it then uses to check permissions.
>
> the problem i'm having is that i can't get the Authorization back out of
> the Subject. here's the code i'm using:
>
> for (Iterator i=subject.getPrincipals().iterator(); i.hasNext();) {
> Principal principal = (Principal) i.next();
> if (principal instanceof Authentication) {
> authentication = (Authentication) principal;
> }
> }
>
> what's happening is that principal instanceof Authentication is failing
> for every principal. if i look at subject in a debugger, i can see that
> it contains one principal, the authentication i set in my LoginModule.
>
> if i grab that one principal explicitly and try to cast it to
> Authentication, i get a ClassCastException.
>
> this reminds me of the earlier problem i was having casting a
> BindableRepository to Repository, which turned out to be a classloader
> issue. i dropped jcr.jar into $CATALINA_HOME/common/lib to solve that
> problem. however, dropping acegi-security.jar into that same location
> doesn't seem to solve this problem.
>
> also, within my AccessManager, there is no Authentication stored within
> Acegi Security's ThreadLocal, even tho was able to access the
> Authentication in both my DavSessionProvider and my LoginModule.
>
> is jackrabbit pulling any classloader tricks or switching threads
> somewhere inside Repository.login()? does JAAS have some weird sort of
> effect here? what else might be causing this problem?
>
> thanks much for the aid you've all given so far! i'm really very close
> to having my whole setup working, and this is the last piece.
>
>
