[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Authentication when using DS for Remote Services?

Hi J,

On 7/11/2014 4:02 PM, J Langley wrote:
> Hi,
>
> I have an OSGI service that I have working as a remote service using the
DS method.  I would like to add password authentication, but I don't see
any way to do that other than programatically registering the service.

To understand your use case, a couple of questions:

1) Are you using the ECF generic provider?  (ECF has a provider
architecture for remote services, and so supports several different
providers, but the ECF generic is the default).

2) On the remote service consumer (client), what do you want to have
happen when the client attempts to connect to the server and needs to
authenticate?  (i.e. provide a password to authenticate and connect)?  
What I mean is, do you want some user interface to appear to request the
user to enter the password?  Or do you want to configure the client
programatically...or via DS...with the password in advance of the actually
connection attempt?  Or something else?

> I am currently using 3.8.x - pulled from the git repo.  I seem to
remember being able to use an extension point to do this somewhere.

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):

org.eclipse.ecf.provider.generic.ServerSOContainer.setConnectPolicy(IConnectHandlerPolicy)

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:

org.eclipse.ecf.core.IContainer.connect(ID, IConnectContext)

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:

org.eclipse.ecf.osgi.services.remoteserviceadmin.IConsumerContainerSelector

The default implementation of the IConsumerContainerSelector service is
this class:

org.eclipse.ecf.osgi.services.remoteserviceadmin.ConsumerContainerSelector

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:

org.eclipse.ecf.osgi.services.remoteserviceadmin.AbstractConsumerContainerSelector.getConnectContext(IContainer,
ID)

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).

Admittedly, all this does need test and/or example code.   If you would
please open an enhancement request I will commit to creating such
example/test code for ECF 3.9.0 coming up in August.   I'm on a bit of a
personal break this weekend, however, so can't do it right away.

>
>
> Am I close?

Yes.   It may not seem so, but you are.

Scott