Re: [ecf-dev] authentication and authorisation with ecf

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Stefan,

On 6/19/2011 9:36 AM, Stefan Below wrote:
> Hi,
> > If the connectHandlerPolicy is set, then it's checkConnect method is 
> > called (connectHandlerPolicy is of type IConnectHandlerPolicy...and 
> > the last parameter...'data'...is the value from the client of the 
> > 'connectData' that's returned from the 
> > connectPolicy.createConnectData call.
> >
> > So to summarize, the IConnectInitiatorPolicy allows the determination 
> > of the client-side 'connectData' during the execution of the 
> > IContainer.connect(ID,IConnectContext) call.  The 'connectData' value 
> > (e.g. password) is then sent to the server.  On the server container 
> > the IConnectHandlerPolicy is consulted (with the 
> > 'data'=='connectData' provided) to determine if the connect request, 
> > should be accepted.
> ok, thanks for your explanation. The Problem was, that i didn 't  set 
> the IConnectInitiatorPolicy. It's working now.
> Is it possible to use JAAS for authentication? 

Yes...it is possible.   There's not any direct support for that in the 
generic provider so far, but with the IConnectInitiatorPolicy and 
IConnectHandlerPolicy hooks I believe it should be possible.  It would 
probably involve using the org.eclipse.equinox.security bundle.

> Or is there a best practise for server side authentication (is it 
> secure to send username/password as a 'connectData' or should i 
> encrypt the password manually?)

It depends somewhat upon your security requirements.  The generic 
provider transport is not, by default, encrypted...but it can/could be 
made so pretty easily.  This is another enhancement that I've thought 
some about, but not yet had the means to fully implement (using some 
encrypted channel for generic provider transport).

If it meets your security requirements then yes you could encrypt the 
password manually.  The connectData can be any Serializable object 
(byte[], String, etc).

> > > How does authorisation work?
> > > I set the RemoteServiceCallPolicy (client side). But the method 
> > > never get called...  (setRemoteServiceCallPolicy(callPolicy) 
> > > returned true)
> >
> > The remote service call policy is called by the service host for the 
> > remote call when a call request has been received, but before it is 
> > actually made on the service host's local service object.  So it's 
> > only going to be called on the host side (I say 'host' rather than 
> > 'server' because it's quite possible for a client to host a 
> > service...and in that case the remote service call 
> > policy.checkRemoteCall would still be called in on the service 
> > host...but it would be a client).  So in other words, you need to set 
> > the remote service call policy on the container that has the service 
> > host (the server container in your situation, I believe).
>
> When i return the authorization roles for the authenticated user on 
> the checkConnect call, how can i access these roles on the 
> RemoteServiceCallPolicy.checkRemoteCall? Is there a default service/impl?

No...not currently.  Access to the roles could be considered an 
enhancement to the generic server/generic provider...e.g. by overriding 
(or just adding to) the appropriate methods in ServerSOContainer.  
Please open a new bug for this enhancement...and consider contributing a 
design and/or patch that would meet your needs.  If we can jointly 
marshal the resources to address it, we will.

Thanks,

Scott