Community
Participate
Working Groups
Build Identifier: ECF 3.4 In order to support remote service call authorization additional API would be needed on remote services: - Interface with method to be able to check authorization of remote service call, something like: public interface IRemoteServiceCallPolicy { public void checkRemoteCall(IRemoteServiceRegistration registration, IRemoteCall remoteCall, ID fromID) throws SecurityException; } - Method to set IRemoteServiceCallPolicy on IRemoteServiceContainerAdapter - [ECF generic] Adapt RegistrySharedObject to perform checkRemoteCall just before the remote service method call Reproducible: Always
If it helps with prototyping, we can setup a dedicated (git) branch including a CI build and automated testing. Just LMK.
I've tried to make a patch (with eGit) with the proposed changes but I don't get a generated patch file. Only when I select "Export in git patch format" I get a patch but it looks as if it has more than only my changes. What's the preferred way to provide the patch?
(In reply to comment #2) > I've tried to make a patch (with eGit) with the proposed changes but I don't > get a generated patch file. Only when I select "Export in git patch format" I > get a patch but it looks as if it has more than only my changes. What's the > preferred way to provide the patch? Hmmm...I don't know about the status of the egit tooling WRT patch creation/application. Markus do you have any suggestions? I suppose we could create a branch as per comment #1. If all the patch stuff and branchging doesn't work out for you Franky we could just take the new API class (i.e. IRemoteServiceCallPolicy.java) and add it...then make changes to the API and impls on master over the next few days and weeks. One thing...since we're entering holiday times things (with me, anyway) may not happen as quickly as usual (because I'm having some time off, etc), but I just want you and everyone to know that this won't drop off...i.e. together we will get it done.
(In reply to comment #2) > I've tried to make a patch (with eGit) with the proposed changes but I don't > get a generated patch file. Only when I select "Export in git patch format" I > get a patch but it looks as if it has more than only my changes. What's the > preferred way to provide the patch? The cmd line clients produces usable patches. Don't know about eGit though. If you happen to have a Github account we might mirror the code there and give you commit rights.
Created attachment 185296 [details] New and modified files for remote service call authorization support
As I don't have a Github account (yet) and very new to git (yesterday was my first experience), I have attached the new/modified files to this bug. Scott: concerning holidays, no worries I have some time off too :-). Thanks both to Scott and Markus for the great support!
(In reply to comment #5) > Created an attachment (id=185296) [details] > New and modified files for remote service call authorization support Question Franky: The file attached here is a zip file, with several (4-5) java files inside of it. How should this be applied? Should I unzip to overwrite the existing files?, or is it a patch of some sort. Also...it doesn't include support for the r-osgi provider-based impl of the remote services API...I might need both your and Markus' help to get this impl of the new API in place. Thanks.
(In reply to comment #7) > (In reply to comment #5) > > Created an attachment (id=185296) [details] [details] > > New and modified files for remote service call authorization support > Question Franky: The file attached here is a zip file, with several (4-5) java > files inside of it. How should this be applied? Should I unzip to overwrite > the existing files?, or is it a patch of some sort. > Also...it doesn't include support for the r-osgi provider-based impl of the > remote services API...I might need both your and Markus' help to get this impl > of the new API in place. > Thanks. Hi Scott, Sorry for the late reply. I was not able to create a patch so they are just plain java files: if nothing has changed in git since I attached these files it would be ok to overwrite the existing files. If this is not acceptable, let me know in which format you would like the changes. About r-osgi, I'll have a look at it. Are there other providers that would be impacted by the API changes? Br, Franky
(In reply to comment #8) <stuff deleted> > About r-osgi, I'll have a look at it. Are there other providers that would be > impacted by the API changes? Not yet...the other providers (xmpp, jms, javagroups, etc) use/depend upon the org.eclipse.ecf.provider.remoteservice code. Thanks. Have a Happy Holiday Franky.
(In reply to comment #9) > (In reply to comment #8) > <stuff deleted> > > About r-osgi, I'll have a look at it. Are there other providers that would be > > impacted by the API changes? > Not yet...the other providers (xmpp, jms, javagroups, etc) use/depend upon the > org.eclipse.ecf.provider.remoteservice code. > Thanks. Have a Happy Holiday Franky. About r-osgi impl of the new remote service API: I don't see where a remote service call is handled like in ecf generic. Question: where is the handling of a remote service call done: in ecf r_osgi provider bundle or directly in r_osgi protocol bundle? If the remote service call handling is done in r_osgi protocol bundle it will be hard to make IRemoteServiceCallPolicy (implementation) set on R_OSGiRemoteServiceContainer do anything useful to support authorization... Any suggestion? Have a happy holiday too!
Assigning to me. I expect to be making this API addition this week along with some others. WRT the r-OSGi question in comment 10 ...I have to look at this myself so don't have immediate answer. Will report after some investigation.
Setting target milestone.
Hi Franky. Question for you: In the zip that you attached, the new class source file (IRemoteServiceCallPolicy.java) has the Composent copyright header. Is this your intention...to transfer/give the copyrights to Composent? (BTW, Composent is my consulting company at the moment). Another alternative is that copyrights are shared between Composent and you personally. It may be better to do this: * Copyright (c) 2004, 2010 Composent, Inc., Franky Bridelance and others. ...same content here * Contributors: * Composent, Inc. and Franky Bridelance - initial API and implementation Or the ordering can be changed (you first)...whatever works for you is fine with me...so just let me know via this bug. Thanks again for the contribution.
Initial checkin of this enhancement released to master. The API was changed...but minor changes only. Specifically, IRemoteServiceCallPolicy method was changed to: /** * Set the remote service call policy to enable authorization on remote service method calls * @param policy Implementation of <code>IRemoteServiceCallPolicy</code> containing authorization specific code * @return <code>true</code> if the underlying provider supports using the policy, <code>false</code> if * it does not support using the policy. * @since 6.0 */ public boolean setRemoteServiceCallPolicy(IRemoteServiceCallPolicy policy); Also IRemoteServiceCallPolicy was changed to: /** * The following method is to be called before the remote service method call to check * if the remote service method call is authorized. Providers supporting this API * should call any available implementing instance prior to actually * invoking the given IRemoteCall. * * @param fromID container ID of the remote caller. * May be <code>null</code>. * @param registration Remote service registration associated * with the given remoteCall. Will not be <code>null</code>. * @param remoteCall Remote method call to invoke locally (assuming this * check passes). Will not be <code>null</code>. * @throws SecurityException if remoteCall is not authorized for the * given caller fromID */ public void checkRemoteCall(ID fromID, IRemoteServiceRegistration registration, IRemoteCall remoteCall) throws SecurityException; An implementation was implemented for the ECF generic provider (i.e. RegistrySharedObject), but no implementation currently exists for r-OSGi. The r0OSGi provider returns false to setRemoteServiceCallPolicy(policy) to signal that it is not supported by that provider.
(In reply to comment #13) > Hi Franky. > Question for you: In the zip that you attached, the new class source file > (IRemoteServiceCallPolicy.java) has the Composent copyright header. Is this > your intention...to transfer/give the copyrights to Composent? (BTW, Composent > is my consulting company at the moment). Another alternative is that > copyrights are shared between Composent and you personally. It may be better > to do this: > * Copyright (c) 2004, 2010 Composent, Inc., Franky Bridelance and others. > ...same content here > * Contributors: > * Composent, Inc. and Franky Bridelance - initial API and implementation > Or the ordering can be changed (you first)...whatever works for you is fine > with me...so just let me know via this bug. > Thanks again for the contribution. Hi Scott, First I wish you a happy new year! I've been on holiday for a while, hence the late reply. It was my intention to give the copyrights because I saw this just as a small addition to existing API, it's not as if I've written some new provider.
Hi Scott, Thanks for the checkin. About r-OSGi, first impression is that it will be hard to have support for RemoteServiceCallPolicy because from code reading it looks like: - remote calls are handled by the r-OSGi protocol bundle and this has no knowledge of the r-OSGi implementation of IRemoteServiceContainerAdapter and hence also not of IRemoteServiceCallPolicy - the remote call message as defined in r-OSGi does not seem to contain any ID of the originator of the call (but maybe that's part of the communication channel?) (In reply to comment #14) > Initial checkin of this enhancement released to master. The API was > changed...but minor changes only. Specifically, IRemoteServiceCallPolicy > method was changed to: > /** > * Set the remote service call policy to enable authorization on remote service > method calls > * @param policy Implementation of <code>IRemoteServiceCallPolicy</code> > containing authorization specific code > * @return <code>true</code> if the underlying provider supports using the > policy, <code>false</code> if > * it does not support using the policy. > * @since 6.0 > */ > public boolean setRemoteServiceCallPolicy(IRemoteServiceCallPolicy policy); > Also IRemoteServiceCallPolicy was changed to: > /** > * The following method is to be called before the remote service method > call to check > * if the remote service method call is authorized. Providers supporting > this API > * should call any available implementing instance prior to actually > * invoking the given IRemoteCall. > * > * @param fromID container ID of the remote caller. > * May be <code>null</code>. > * @param registration Remote service registration associated > * with the given remoteCall. Will not be <code>null</code>. > * @param remoteCall Remote method call to invoke locally (assuming this > * check passes). Will not be <code>null</code>. > * @throws SecurityException if remoteCall is not authorized for the > * given caller fromID > */ > public void checkRemoteCall(ID fromID, IRemoteServiceRegistration > registration, IRemoteCall remoteCall) throws SecurityException; > An implementation was implemented for the ECF generic provider (i.e. > RegistrySharedObject), but no implementation currently exists for r-OSGi. The > r0OSGi provider returns false to setRemoteServiceCallPolicy(policy) to signal > that it is not supported by that provider.
The suggested API has been added in the remote service API for ECF 3.5. Resolving as fixed. Thanks again for the use case and suggested design.
