You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2011/08/10 04:57:45 UTC

[Fwd: Re: Ease of use, development & deployment]


Re: [Fwd: Re: Ease of use, development & deployment]

Posted by Peter Firmstone <ji...@zeus.net.au>.
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.

Re: [Fwd: Re: Ease of use, development & deployment]

Posted by Greg Trasuk <tr...@stratuscom.com>.
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.
-- 
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com