Not being critical, just curious.
Cheers,
Peter.
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?
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?
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.
