Gregg Wonderly wrote:
On 8/11/2011 9:34 PM, Peter Firmstone wrote:
Gregg Wonderly wrote:
I've done this a couple of different ways. I do have a server side
invocation
handler that can extract a Principal from the calling context to
find an
identity, and then use JAAS to login to check your login credentials.
Interesting, so you get the current AccessControlContext, because the
field
context is private, you must have a DomainCombiner? Then you'd need
to create a
new AccessControlContext, with your DomainCombiner implementation, call
doPrivileged (which causes the combiner to be called). With the
DomainCombiner,
you retrieve the assignedDomain's, the call getPrincipal's on all
ProtectionDomains, then find a common subset of Principals that all
ProtectionDomain's have?
Then what?
No, I just do as Greg described with inspecting the
AccessController.getContext() value for the "credentials", tuck those
into a JAAS Callback handler, create a LoginContext with the
appropriate context name, call LoginContext.login(), and if that
succeeds, make the method call with Sobject.doAs(). This does two
things. One, it lets me use AccessController/checkPermission, if I
want to in server code. But second, it performs the authentication on
each call in. The overhead of that check, for me, is the issue to
decide on. If it seems too much, then use the other method I
described by authenticating once and returning a service proxy that
has the authorization plugged in that is appropriate for that identity.
You're getting the credentials from the Subject in
SubjectDomainCombiner AccessControlContext.getDomainCombiner,
if(combiner instanceof SubjectDomainCombiner) { subject =
((SubjectDomainCombiner) combiner).getSubject();}
subject.getPublicCredentials();
If & when it exists.
My JNI interface to PAM allows me to extract/create user and group
Principals,
put those into a Subject and then doAs() from there. This is what
you would
use in a complex application that needs absolute authentication
control when a
credential change should disallow access instantly.
I predominately have no worries about "stolen remote objects" or
revoked
access rights. And so single authentication is fine with me, and I
use a
factory interface with a single method that I pass
identity/credentials to
with remote call.
I'm guessing you do this over TCPEndpoint's? This is for private
networks?
I do it over SSL mostly to hide the credentials that are in flight.
This is not great because it is in no way using single sign on
services. But, its what works. My customers use either a single
"tech" sign on, or have PAM support for whatever corporate
authentication system they use. They don't ask questions about me
actually having passwords in my code and passing them around. I keep
that information tightly controlled in the code, and don't log it or
otherwise expose it.
This is where I feel JAAS falls down. It should do all of this for
us! We should be able to call a factory method that returns an
authenticated Subject. The problem is really Applets. Because they
exist, and mobile code allows "unknown" things to happen, the JAAS
developers appear to have been put off by the fact that if Java code
could get "authenticated" Subjects, ready for use, that Applets could
steal into a corporate environment from a web page and call out to
enterprise applications and "do bad stuff". They don't seem to
believe in their own security implementation...
Interesting, we've got to keep focusing on this if we're going to fix it.
Cheers,
Peter.
Gregg
The implementation of that interface uses JAAS to authenticate (I
have a
LoginModule that uses JNI interfaces to PAM for *NIX auth that I
"plugin" to
the server). If auth succeeds, execution continues to create an
instance of
the service object (if needed it might be a singleton depending on the
application) and that is then wrapped by the authorization proxy
object which
is exported and wrapped into a Leased smart proxy which thus has the
remote
reference to the authorization proxy object on the server. That
smart proxy is
then what the client uses.
Gregg Wonderly
Thank you,
Peter.
On 8/9/2011 9:40 PM, Peter Firmstone wrote:
Gregg Wonderly wrote:
On 8/9/2011 7:57 PM, Peter Firmstone wrote:
I'm interested, I've been thinking about this too, what's your
current service
interface?
The service interface is "the service interface". The mechanism
just uses a
proxy, delegating object. Thus, if you currently have a service
object, you
just create an instance of your security object, passing in the
service
object, and then export the security object for remote use.
That keeps you from having to support a "single" role model by
having that
codified into your application. Instead, the service can be
deployed with an
arbitrarily complex authorization implementation making it quite
flexible. You
can even use Configuration to specify the security implementation
class.
Gregg Wonderly
So it implements the same interface as your service, but
encapsulates it.
So how do you log in, how does it track users? I'm guessing it's
got something
to do with associating threads.
Regards,
Peter.
