I'm currently experimenting with a new authorization layer for java,
post JEP 411.
I would like your thoughts around threads.
This is intended to be simpler than Java's existing authorization layer,
support user Subjects and code based authorization.
Concepts:
1. Application code has no privileges, unless a privileged call is made
(implements Callable), the privileges are only in force during
execution of the Callable and are not transferable to other threads.
2. A Thread with a stack that only contains code visible to the
platform ClassLoader is considered privileged.
3. Privileged means it has defined privileges, it doesn't mean
AllPermission.
Agents will be used to instrument the Java API for guard checks (would
be nice if OpenJDK can annotate these methods or do something to help us
identify these locations).
Clearly, this will break a lot of existing code, many applications
simply won't run, because they don't utilise the API. It would work
fine for new applications.
In Java's existing authorization layer implementation (designed prior to
the introduction of Executor frameworks), a thread inherits the stack
context of the thread which created it, with executors, tasks don't
inherit the context of the thread which places the task. The new
framework isn't able to capture the creating threads context, so it
makes more sense to treat anything outside a privileged call, or system
thread as unprivileged, it does however capture the caller when creating
a privileged task, this is a Task that has privileged access, so it's
important that it is not allowed to escape.
I am thinking about allowing privileged domains, such that if a library
(which doesn't implement privileged calls), may be thought of as a
system domain, should it create threads, then provided those threads
only have privileged domains on the stack, guard checks may proceed.
For unprivileged application code, all guard checks fail.
Any thoughts or questions?
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
