[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] RemoteService + Context

Hi Franky, hi Scott,

Franky, thanks for letting me know about the previous discussion - it is indeed quite similar to what I'm doing.

More about our use case - when a request to a remote service is executed, the security context has to be passed together with the request. The remote platform should receive the request and put the context in a thread local (before the actual method execution), so the security details are available for the current call stack.

Scott, I understand that something similar should be provider specific, so I am using ecf generic provider.

The solution I found so far is based on aspects. We are weaiving org.eclipse.ecf.provider.remoteservice so:
- When a new org.eclipse.ecf.provider.remoteservice.generic.Request is created the security context is put in the RemoteCallImpl instance of the Request.
- Before each execution of the org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceRegistrationImpl.callService(RemoteCallImpl) the security context is get from the RemoteCallImpl parameter and put in a thread local.

Do you see any problems with this approach or maybe suggest a more elegant solution?


On 27.10.2010 г. 16:25, Franky Bridelance wrote:
That's quite similar to what I'm doing. That's the reason why I started the discussion about how to add authorization on remote service calls via the proposed IRemoteServiceCallPolicy interface. The discussion about this matter is on hold for some time due to the ECF 3.4 release. Maybe we can start the discussion again once 3.4 has been released?
Radostin: I will reply on the original email thread about the authorization discussion so that you can follow what has been discussed up till now.
2010/10/25 Scott Lewis <slewis@xxxxxxxxxxxxx>

On 10/25/2010 2:42 AM, Radostin Surilov wrote:

We are building an application based on OSGI services. Everything is working fine in one VM but now we want to integrate a remote services implementation.
ECF seems a great choice - thank you for the work so far!

In our current implementation we have session and security contexts in ThreadLocals. Now when talking about remote services (which are in different VM) we want to pass
the session and security tokens over the "wire" and to use them in remote VMs.

How we can extend ECF to pass such parameters? Is it going to be a provider specific fix (ecf generic, r-osgi, etc.) or the fix can be done in a more abstract layer?

ECF has the notion of a 'connect context', which is used to pass credentials/credentials to the remote container upon container connection.  This is represented in the API by the IConnectContext in the IContainer.connect(ID,IConnectContext) call.  The IConnectContext *usually* has password information, but it can contain other information (e.g. serializable forms of the session and security contexts that you wish to send).

Note also that there is a way to set the connect context for remote service container adapters...i.e. via IRemoteServiceContainerAdapter.setConnectContextForAuthentication(IConnectContext).  This is the connect context that's used when connections are formed implicitly to targetID by the call to (e.g.) IRemoteServiceContainerAdapter.getRemoteServiceReferences(targetID, "org.foo.Foo",null);

The use of the IConnectContext for/by any given provider is indeed provider-specific...as the provider dictates what information (from the IConnectContext callback) is actually sent over the wire upon connection.

For the generic provider, it's also possible to extend the RegistrySharedObject (in org.eclipse.ecf.provider.remoteservice bundle), which is the code responsible for sending remote call requests and responses.  So I believe it would be possible to extend this with call-specific information.

If your use case requires/implies some new API then we can certainly consider that for future versions of ECF...so it might be useful for me and the entire community if you describe what you are doing a little further.



ecf-dev mailing list

_______________________________________________ ecf-dev mailing list ecf-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/ecf-dev