Authorization layer API and low level access checks.

[Peter Firmstone]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210623/8baaa7cc/attachment.htm>