Greg Trasuk wrote:
On Tue, 2011-08-09 at 22:57, Peter Firmstone wrote:
...> 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.
Assuming you're using endpoints that support the credential you want to
login with (i.e. client logs in with a KerberosLoginModule, then uses a
KerberosEndpoint), the client simply has to make sure they call the
service proxy inside a Subject.doAs(loginContext.getSubject()){ } call.
The service proxy will convey the compatible credentials, then on the
service side, you can recover the client subject like so...
import net.jini.export.ServerContext;
import net.jini.io.context.ClientSubject;
...
ClientSubject cSubject= (ClientSubject)
ServerContext.getServerContextElement(ClientSubject.class);
Subject subject=cSubject.getClientSubject();
...
And use the subject as you wish to perform authorization.
Cheers,
Greg.
Hmm, that's how we currently perform authorisation, I think Gregg's
talking about using another proxy or invocation handler to encapsulate
the existing service, to perform the login then do Subject.doAS.
At least that's what I'm getting so far.
Since you can have multiple LoginModule's in a system, I guess you could
have a smart proxy that contained a LoginModule, with the SPI defined in
META.INF, maybe that's what Gregg's doing?
Sorry, just guessing.
Cheers,
Peter.
