Java developers such as myself need a light weight API that allows
developers to continue to support authorization and access controls,
without dictating how that should be implemented or whether these
controls are fine grained, course grained, based solely on user
authorization or also includes code authorization.
SecurityManager has been deprecated, we need to commence removal of
dependencies on deprecated Java API's, however we are unable to make a
decision on how to proceed without understanding the level of support
that OpenJDK will provide for an authorization layer in future. (If this
is zero, we at least need to know).
Currently there is no such API that allows developers who require an
authorization layer to continue to supporting Java 8 as well future
versions Java with one development codebase. It's a non goal of this to
debate the need for cross version support. I simply wish to open
discussions on alternatives and whether OpenJDK is considering them.
SecurityManager API low level functionality replacements:
1. StackWalker - Can stack walker be back ported to Java 8?
2. Permission checks - Can we have low level Guard service hooks to
replace existing permission checks?
Note: I'm not sure how to replace an inherited AccessControlContext
(with a new implementation based on StackWalker functionality) at thread
creation time, as it must be created when threads are created, possibly
by using ThreadFactory everywhere, but this doesn't cover all threads.
How to cater for virtual threads?
For replacement of permission checks, I propose using a Guard service
authorization API (feel free to propose alternatives).
The proposed authorization layer API would utilize the existing Provider
Service mechanism to register authorization layer hooks, for use in
permission checks by JDK code, and library code that implements their
own Permission's:
GuardFactory runtimeGuardFactory = GuardFactory.getInstance("RUNTIME");
Guard createClassLoader =
runtimeGuardFactory.orders("createClassLoader", null);
// Permission check
createClassLoader.check();
Guard exitVM = runtimeGuardFactory.orders("exitVM", null);
exitVM.check();
GuardFactory socketGuardFactory = GuardFactory.getInstance("SOCKET");
// Permission check
socketGuardFactory.orders(host, action).check();
GuardFactory fileGuardFactory = GuardFactory.getInstance("FILE");
fileGuardFactory.orders(path, actions).check();
Guard service hooks, are based on existing Permission types (independent
instances to avoid circular deadlocks), developers only need implement
those relevant to them and may only use checks for users if they wish:
"AWT"
"FILE"
"SERIALIZABLE"
"MANAGEMENT"
"REFLECT"
"RUNTIME"
"NET"
"SOCKET"
"URL"
"FILE-LINK"
"SECURITY"
"SQL"
"LOGGING"
"PROPERTY"
"MBEAN"
"MBEAN-SERVER"
"MBEAN-TRUST"
"SUBJECT-DELEGATION"
"TLS"
"AUTH"
"KERBEROS-DELEGATION"
"KERBEROS-SERVICE"
"PRIVATE-CREDENTIAL"
"AUDIO"
"JAXB"
"WEB-SERVICE"
I would like to suggest adding a new provider type:
"PARSE-DATA" - To be called by any code about to parse data, eg
deserialization, XML, JSON, SQL, etc. The use case for this is for
servers to grant it to authenticated users (user supplied input data),
so that it can only be performed following user authentication.
Existing Permission implementations
--
Regards,
Peter Firmstone
