Re: Best Practices for Handling Client Authentication

After reading over the suggestions from the list, I decided to go the
proxy route.  However, there are some non-obvious issues here.

Note: I wrote my own authentication proxy, but it ended up looking
almost exactly like the one in the Harvester distro.

Consider the TransactionManager.  I wrap my manager in an
authentication proxy, which works fine when I call a method to create
transaction.  However, when I attempt to call my JavaSpace with the
resulting transaction, things get messy.  Specifically, the
Transaction object seems to have a reference to the
TransactionManager that created it.  Thus, when the Transaction
object is serialized and sent to the remote server, the
TransactionManager is serialized as well.  In my case, the Proxy is
serialized, which means my proxy InvocationHandler is serialized as
well, which initially caused problems because I did not have my
codebase setup properly to serve this unknown class to the server.

However, even after setting up the codebase so that the server now
knows about my custom InvocationHandler, things are still amiss.  At
the moment, I'm getting a weird "SecurityException: Prohibited
package name: java.lang" in the object unmarshaling for what I'm
guessing is my InvocationHandler.


In general, I'm a little reluctant to have my authentication wrapper
proxies being sent across the wire, but I'm not sure how to avoid it
in this case.  Any ideas?

Thanks,
Brian


On Apr 13, 2006, at 11:49 AM, Brian Ferris wrote:

> I'm setting up my Javaspace (using Blitz on the backend) to require
> client authentication using JAAS.  Everything is setup properly
> (constraints on the server side, LoginContext on the client side) and
> I've gotten my client to properly authenticate.  However, I've run
> into a general design question concerning LoginContexts.
>
> At some point I have to call Subject.doAs to elevate my privileges.
> I have two options:
>
> 1) I can call this method once to wrap all subsequent code
> 2) I can call this method every time I wish to access the privileged
> object (in this case my JavaSpace)
>
> The first option is tricky, because my application is quite complex
> and there is no one nice entry point to do the login.
>
> If anything, #2 appeals to me.  Specifically, it seems wrapping the
> Javaspace in some sort of Proxy that automatically catches method
> calls and recalls them with elevated privileges would be cool.  Has
> anyone every done something like this?  Are there any existing JINI
> support classes for doing this?  Or should I suck it up and go with
> option #1?
>
> Thanks,
> Brian Ferris
>
> ======================================================================
> =====
> To unsubscribe, send email to [email protected] and include in
> the body
> of the message "signoff JAVASPACES-USERS".  For general help, send
> email to
> [email protected] and include in the body of the message "help".
>
> To view past JAVASPACES-USERS postings, please see:
> http://archives.java.sun.com/archives/javaspaces-users.html

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html