JEP411: Missing use-case: Monitoring / restricting libraries

[Peter Firmstone]

On 13/05/2021 10:59 pm, Sean Mullan wrote:
>
> The JEP does have a section on this:
>
> "In future JDK releases, we may degrade the Security Manager APIs so 
> that they remain in place but have limited or no functionality. For 
> example, we may revise AccessController::doPrivileged simply to run 
> the given action, or revise System::getSecurityManager always to 
> return null. This would allow libraries that support the Security 
> Manager and were compiled against previous Java releases to continue 
> to work without change or even recompilation. Once the compatibility 
> risk has declined to an acceptable level, we expect to remove the APIs."
>
> So, if the JEP is targeted to 17, then the Security Manager will be 
> deprecated for removal but will still be fully functional and 
> supported in 17.
>
> *Disclaimer: The next part is forward thinking, and subject to change.*
>
> Once we start degrading the APIs, the functionality of the Security 
> Manager may not fully work as before, so in that sense you might 
> consider it "removed". We don't yet have a definitive timeline for 
> that, it may occur in the next release, or it may not, but it will 
> probably occur within a few releases after the release it is targeted to.
>
> --Sean
>
It will be important for existing JAAS login mechanisms and 
AccessControlContext's for Subject's are still functional and preserved 
so that TLS clients and servers can authenticate.   The 
AccessControlContext would only need to contain an array with only one 
ProtectionDomain, containing the Subject.


-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.