[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] Authentication when using DS for Remote Services?
- From: J Langley <jlangley@xxxxxxxxxxxxxxxxx>
- Date: Mon, 14 Jul 2014 22:36:29 -0500 (CDT)
- Delivered-to: firstname.lastname@example.org
- Thread-index: F0/DGXijOC+GsPB40ifXkdKshlnDTQ==
- Thread-topic: Authentication when using DS for Remote Services?
Hi - thanks for the quick reply!
First, I am using the ECF Generic provider for the prototyping that I am doing. Most of the testing that I have done is based directly on the remoteservices.hello.ds client and host examples. We currently have a monolithic application that employs OSGi services (all registered & resolved with DS) at the component interfaces to allow us to develop and test each one independently. We also expected to break a section out of the application in the future and run it remotely - the future arrived last week!
The user currently logs into the application (we're hooking Apache Shiro for authentication) on the client side. I expect to pass the username and possibly a token with a timeout value across to a server that can then configure things based on the user that has connected. I do not plan to create another dialog for the user to login other than the current dialog that we already use when a user initially launches the application.
I created a feature request: https://bugs.eclipse.org/bugs/show_bug.cgi?id=439577 - I worded it to the best of my knowledge - feel free to update based on our conversation in this thread. I will start looking into the interfaces that you mentioned and see if I can put together an example that just passes a system property across for authentication.
----- Original Message -----
To: "Eclipse Communication Framework (ECF) developer mailing list." <ecf-dev@xxxxxxxxxxx>
Sent: Friday, July 11, 2014 5:20:04 PM
Subject: Re: [ecf-dev] Authentication when using DS for Remote Services?
On 7/11/2014 4:02 PM, J Langley wrote:
> 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
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
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
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
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.
ecf-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit