<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>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.<br>
    </p>
    <p>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).<br>
    </p>
    <p>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.<br>
    </p>
    <p>SecurityManager API low level functionality replacements:</p>
    <ol>
      <li>StackWalker - Can stack walker be back ported to Java 8?</li>
      <li>Permission checks - Can we have low level Guard service hooks
        to replace existing permission checks?</li>
    </ol>
    <p>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?<br>
    </p>
    <p>For replacement of permission checks, I propose using a Guard
      service authorization API (feel free to propose alternatives).</p>
    <p>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:<br>
    </p>
    <p>GuardFactory runtimeGuardFactory =
      GuardFactory.getInstance("RUNTIME");
      <br>
      <br>
      Guard createClassLoader =
      runtimeGuardFactory.orders("createClassLoader", null);
      <br>
      <br>
      // Permission check
      <br>
      <br>
      createClassLoader.check(); <br>
    </p>
    <p>Guard exitVM = runtimeGuardFactory.orders("exitVM", null);</p>
    <p>exitVM.check();</p>
    <p><br>
      GuardFactory socketGuardFactory =
      GuardFactory.getInstance("SOCKET"); <br>
    </p>
    <p>// Permission check
      <br>
      socketGuardFactory.orders(host, action).check();<br>
    </p>
    <p>GuardFactory fileGuardFactory = GuardFactory.getInstance("FILE");</p>
    <p>fileGuardFactory.orders(path, actions).check();</p>
    <p><br>
    </p>
    <p>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:</p>
    <p>"AWT"<br>
       "FILE"<br>
       "SERIALIZABLE"<br>
       "MANAGEMENT"<br>
       "REFLECT"<br>
       "RUNTIME"<br>
       "NET"<br>
       "SOCKET"<br>
       "URL"<br>
       "FILE-LINK"<br>
       "SECURITY"<br>
       "SQL"<br>
       "LOGGING"<br>
       "PROPERTY"<br>
       "MBEAN"<br>
       "MBEAN-SERVER"<br>
       "MBEAN-TRUST"<br>
       "SUBJECT-DELEGATION"<br>
       "TLS"<br>
       "AUTH"<br>
       "KERBEROS-DELEGATION"<br>
       "KERBEROS-SERVICE"<br>
       "PRIVATE-CREDENTIAL"<br>
       "AUDIO"<br>
       "JAXB"<br>
       "WEB-SERVICE"</p>
    <p>I would like to suggest adding a new provider type:</p>
    <p>"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.</p>
    <p>Existing Permission implementations<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Regards,
 
Peter Firmstone</pre>
  </body>
</html>