Rick,
Out of curiosity, does Apache Derby have a need for an Authorization layer?
We have tooling to generate our policy files, which simplifies the
process a lot, we also have highly scalable and performant
SecurityManager and Policy implementations which are compatible with
standard Java policy files.
This is available under an AL2.0 license.
I'm hoping that OpenJDK will create some hooks for permission checks, so
that we can continue to provide an authorization layer for Java,
following JEP 411.
I'll be using StackWalker to reproduce AccessController's stack walk.
We also have existing classes which wrap AccessControlContext, so we
would use ThreadLocal's to preserve subject.
--
Regards,
Peter.
On 16/06/2021 1:56 am, Alan Bateman wrote:
On 15/06/2021 15:10, Rick Hillegas wrote:
:
When I tried to build Derby with the Rampdown Phase One build of open
JDK 17 (17-ea+26-2439), I saw many warnings related to the
deprecation of Security Manager classes and methods, undoubtedly the
consequence of JEP 411 (https://openjdk.java.net/jeps/411). Derby,
like Tomcat, embraced the Security Manager early on. Permissions
checks were rototilled across the whole code base and our
distributions ship with several template policy files, which we
encourage users to customize for their environments. The "Configuring
Java Security" section of our Security Guide explains how to do this
(https://db.apache.org/derby/docs/10.15/security/index.html).
My build only reported the first 100 warnings. It is likely that
there are many more.
Yes, JEP 411 deprecates a number of APIs for future removal. There
probably isn't much to do right now except to be aware that the APIs
are earmarked for removal in some future release. I've no doubt there
will be another JEP when that time comes. I assume you know about
@SuppressWarnings("removal"), which you can use to suppress the
warnings for now. The JDK usages of these APIs are using
SuppressWarnings as the JDK is compiled with -Xlint set to made
warnings fatal.
-Alan
