This section adds authentication to a remote service.
ECF has a provider architecture for remote services, and so supports several different providers, but the ECF generic is the default.
For the ECF generic provider, it is very possible to programatically configure both the host and consumer for performing authentication during connect. Because OSGi does not specify any of this, however, it does require the use of ECF API.
Specifically, on the host/server, the following API allows the connect handler policy callback to be specified during configuration (e.g. DS activation):
There are two ways to setup/call this method on the host/server container instance. One way is to configure this prior to the remote service export, the other way is to specify your own IHostContainerSelector service which will be called during the remote service export. See the discussion of the IConsumerContainerSelector service customization below...it's quite similar.
On the consumer/client, this method is ultimately called by the ECF remote service admin impl when the remote service is discovered and imported:
The connect context that's passed in to this call contains callbacks that can be used to (e.g.) show the user an interface for requesting the password entry from a user, or reading/using a password from somewhere (local store) and using that or something else (i.e. 2 above), or even returning a value specified via a system property (e.g.).
For ECF remote services, the easiest way to specify a non-null IConnectContext is to register a custom implementation of this service:
The default implementation of the IConsumerContainerSelector service is this class:
When the ECF remote service admin impl imports a remote service, the IConsumerContainerSelector whiteboard service is called back to select/create/configure the consumer container (and host container in the case of IHostContainerSelector).
To customize the IConnectContext used during the connect call, override this method:
the default impl returns null. Your impl would return a non-null IConnectContext, and then register an instance with the IConsumerContainerSelector service type. Then, during remote service import, your getConnectContext impl method will be called, and it may return an appropriate connect context (see also the utility class org.eclipse.ecf.core.security.ConnectContextFactory for creating IConnectContext impls).
We have 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).
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 we did it in different ways for the host/server and client/consumer respectively.
For the host/server, we created the generic server container instance via the IContainerManager, and then configured it with an IConnectHandlerPolicy in the host Activator start . This is all done *prior* to the registration and export of the remote service that occurs on line 43 of .
For the consumer/client, we registered a new instance of IConsumerContainerSelector in the Activator , and this consumer container selector's createContainer method gets called *when the remote service is discovered for the first time*. The createContainer method  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.