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 <V> 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 <V> Callable<V> withContext(Callable<V> 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<j...@zeus.net.au> 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.
