Re: SSL Secure Endpoints never fully utilised by River services
Right, so I've added a couple of convenience methods to net.jini.security.Security Now all service implementations capture their context at creation and executors run with that context, when performing remote calls. /** * Decorates a callable with the given context, and allows it to be * executed within that context. * * @param The type of the object returned from Callable.call(). * @param callable The callable to execute with the given context. * @param context The context in which the callable is to execute. * @return The callable to be submitted to an ExecutorService. */ public static Callable withContext(Callable callable, AccessControlContext context) public static Runnable withContext(Runnable runnable, AccessControlContext context) On 22/04/2018 12:08 AM, Gregg Wonderly wrote: There are lots of details around lost login context. I had to wire up some of that in my swing/awt infrastructure. This is required so that those event/callbacks also assert the right credentials. Gregg Sent from my iPhone On Apr 21, 2018, at 1:06 AM, Peter wrote: To be more accurate it limits the call backs to anon client connections, which is vulnerable to man in the middle attacks. The way to fix this is to ensure the login context is preserved and utilised when making call backs. On 21/04/2018 9:57 AM, Peter wrote: It's clear to me now that the Jini team never fully completed the integration of JERI with Jini. The evidence: call backs to event listeners are not run with the service's logged in subject, this prevents secure endpoints from establishing connections for call backs. I have rectified this in my local code and am running tests. Just thought you might be interested to know. Regards, Peter.
Re: SSL Secure Endpoints never fully utilised by River services
There are lots of details around lost login context. I had to wire up some of that in my swing/awt infrastructure. This is required so that those event/callbacks also assert the right credentials. Gregg Sent from my iPhone > On Apr 21, 2018, at 1:06 AM, Peter wrote: > > To be more accurate it limits the call backs to anon client connections, > which is vulnerable to man in the middle attacks. > > The way to fix this is to ensure the login context is preserved and utilised > when making call backs. > >> On 21/04/2018 9:57 AM, Peter wrote: >> It's clear to me now that the Jini team never fully completed the >> integration of JERI with Jini. >> >> The evidence: call backs to event listeners are not run with the service's >> logged in subject, this prevents secure endpoints from establishing >> connections for call backs. >> >> I have rectified this in my local code and am running tests. >> >> Just thought you might be interested to know. >> >> Regards, >> >> Peter. >> >
Re: SSL Secure Endpoints never fully utilised by River services
To be more accurate it limits the call backs to anon client connections, which is vulnerable to man in the middle attacks. The way to fix this is to ensure the login context is preserved and utilised when making call backs. On 21/04/2018 9:57 AM, Peter wrote: It's clear to me now that the Jini team never fully completed the integration of JERI with Jini. The evidence: call backs to event listeners are not run with the service's logged in subject, this prevents secure endpoints from establishing connections for call backs. I have rectified this in my local code and am running tests. Just thought you might be interested to know. Regards, Peter.
SSL Secure Endpoints never fully utilised by River services
It's clear to me now that the Jini team never fully completed the integration of JERI with Jini. The evidence: call backs to event listeners are not run with the service's logged in subject, this prevents secure endpoints from establishing connections for call backs. I have rectified this in my local code and am running tests. Just thought you might be interested to know. Regards, Peter.
