Re: [ecf-dev] Authentication when using DS for Remote Services?

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

On 7/24/2014 10:53 PM, Peter Hermsdorf wrote:
> Hi Scott,
>
> Thanks for providing this example. This is something which was on my 
> list for some time now.

Sure.   A couple of technical notes:

1) There are multiple ways to configure an ECF container instance 
(server or client) prior to use for remote services.   In order to show 
this wrt configuring authentication, in this example I did it in 
different ways for the host/server and client/consumer respectively.

For the host/server, I created the generic server container instance via 
the IContainerManager, and then configured it with an 
IConnectHandlerPolicy in the host Activator start [1].  This is all done 
*prior* to the registration and export of the remote service that occurs 
on line 43 of [1].

For the consumer/client, I registered a new instance of 
IConsumerContainerSelector in the Activator [2], and this consumer 
container selector's createContainer method gets called *when the remote 
service is discovered for the first time*.   The createContainer method 
[2] not only creates the ecf.generic.client container (in super class), 
but it also sets an instance of IConnectInitiatorPolicy, which gets 
called to create the connectData holding the appropriate credentials.

2) The default ecf generic container does *not* use encryption for the 
connectData, so such credentials could be intercepted.   It is possible, 
however, to use an an SSLServerSOContainer instance, which uses SSL for 
the connection.   As you might expect, this does require necessary 
certificate availability and keystore configuration, to allow for the 
SSL socket connection to be used.

Scott

[1] com.mycorp.examples.timeservice.host.generic.auth.Activator
[2] 
com.mycorp.examples.timeservice.consumer.ds.generic.auth.GenericAuthConsumerContainerSelector

> Bye, Peter
>
>
> Am 25.07.2014 04:12, schrieb Scott Lewis:
> > Hi Folks,
> >
> > I've created a two new example bundles (one customizing the remote 
> > service host to do authentication, the other customizing the remote 
> > service consumer/client to do the sending of the authentication 
> > information (i.e. username/password).  See [1] for details.
> >
> > Mea culpa:  I was a incorrect below in describing the procedure for 
> > passing authentication information (username/password) in the 
> > connectData for the remote service consumer.   Rather than overriding 
> > getConnectContext(), it involved defining and setting an 
> > IConnectInitiatorPolicy instance upon consumer container creation.  
> > This is shown in the consumer example code (in this class in the 
> > example: 
> > com.mycorp.examples.timeservice.consumer.ds.generic.auth.GenericAuthConsumerContainerSelector).
> >
> > Thanks,
> >
> > Scott
> >
> > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=439577#c2
> >
> > On 7/21/2014 11:25 AM, Scott Lewis wrote:
> > > Hi J,
> > >
> > > Sorry about the slow reply...over past two weeks I've been 
> > > completely focused on testing ECF 3.9 against the OSGi R6 CT 
> > > (compatibility test suite).
> > >
> > > I've asked you some high-level questions on the bug [1]...about the 
> > > desire for the example you requested for setting up ECF generic 
> > > authentication.
> > >
> > > A couple of quick responses below.   If you would like to contact me 
> > > directly for support please just email me at slewis at composent.com.
> > >
> > > On 7/15/2014 9:48 PM, J Langley wrote:
> > > > I believe that I am a bit closer to getting this to work using the 
> > > > hello remote services example. I am using zeroconf for discovery.
> > > >
> > > > On the host side, I have registered a service for 
> > > > IHostContainerSelector.  It extends the HostContainerSelector, 
> > > > overriding the createContainer method to use the parent to actually 
> > > > create the container, but then sets an IConnectHandlerPolicy policy 
> > > > on the container before returning it.  I have verified that the 
> > > > policy is called when the consumer is connected, but the 
> > > > connectData is always null.
> > > >
> > > > On the client side, I have registered a service for 
> > > > IConsumerContainerSelector.  It extends the 
> > > > ConsumerContainerSelector, overriding the getConnectContext and 
> > > > connectContainer methods.  However, these methods are never 
> > > > called.  I believe that this is because the connectTargetID 
> > > > parameter in the ConsumerContainerSelector::selectConsumerContainer 
> > > > method is always null.
> > > > So far, I think that it is because the endpoint discovery has not 
> > > > occurred at this point.
> > >
> > > Yes, this seems right to me.  The 
> > > IConsumerContainerSelector.selectConsumerContainer is called when 
> > > the RSA.importService method is called, and with the 
> > > BasicTopologyManager, importService is called upon endpoint 
> > > discovery.  So the sequence typically looks like this:
> > >
> > > 1.  <network discovery occurs>
> > >     -> creates EndpointDescription instance (ed)
> > > 2.  Topology Manager (BasicTopologyManager) takes ed and calls 
> > > RemoteServiceAdmin.importService(ed)
> > > 3.  <ECF's RSA impl>
> > >         -> Gets IConsumerContainerSelector and calls 
> > > selectConsumerContainer(ed)
> > >         -> Creates TCPClientSOContainer, calls connect after calling 
> > > getConnectContext()
> > > etc.
> > >
> > > The reason I say 'typically' is that the RSA spec makes it possible 
> > > have/use a custom topology manager.  As a compliant impl, ECF 
> > > supports this topology manager customization, it's possible for 
> > > others to create/use a custom topology manager...and not use the 
> > > BasicTopologyManager (which is the ECF default topology manager). 
> > > But the upshot is that you are right, with the BasicTopologyManager 
> > > the endpoint description discovery triggers the RSA.importService, 
> > > which calls the IConsumerContainerSelector.
> > >
> > > > I was finally able to override the selectConsumerContainer and set 
> > > > the context for authentication on the adapter.  Now when I have a 
> > > > breakpoint at SOContext.connect - I see the connect context that I 
> > > > set for the adapter.
> > >
> > > Ok, that seems right.  Please let me know how/if I can help 
> > > further.  Please also feel free to use bug [1] if you wish.
> > >
> > > > I am still receiving null on the host side though.  Also, it 
> > > > doesn't appear that the return value from the IConnectHandlerPolicy 
> > > > is being used.  I will update tomorrow with any progress.
> > >
> > > Thanks,
> > >
> > > Scott
> > >
> > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=439577
> > >
> > >
> > > _______________________________________________
> > > ecf-dev mailing list
> > > ecf-dev@xxxxxxxxxxx
> > > To change your delivery options, retrieve your password, or 
> > > unsubscribe from this list, visit
> > > https://dev.eclipse.org/mailman/listinfo/ecf-dev
> >
> > _______________________________________________
> > ecf-dev mailing list
> > ecf-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or 
> > unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/ecf-dev
>
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ecf-dev