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?
Thanks,
Radostin
On 27.10.2010 г. 16:25, Franky Bridelance wrote:
Hi,
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.
br,
Franky
2010/10/25 Scott Lewis <slewis@xxxxxxxxxxxxx>
Hello,
On 10/25/2010 2:42 AM, Radostin Surilov wrote:
Hello,
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.
Thanks,
Scott
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
|
