Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [External] : Pending removal of security manager


On 4/15/21 10:37 PM, arjan tijms wrote:

This new JEP just came out: <>

with SecurityManager being marked for removal in recent JDK 17 build[1], do you have an idea wrt impact on Authentication & Authorization specs and implementations?

I briefly checked other specs and from what I can see, most SecurityManager usages there are about checks for its availability and execution through AccessController when SM is available. AccessController as such is marked for removal too.

Other spec which can be affected by this is Connector spec, where one part of the spec defines EIS integration-specific security details. Therefore I think SM removal has an impact on implementations of this spec as well. (note that connectors spec available on spec page is incomplete[2])

Some specs also defines their own permission classes. Since these will become irrelevant going forward, should we deprecate them within EE 10?



Jakarta EE is specifically mentioned:

"Jakarta EE has several requirements on the Security Manager. These must be either relaxed or removed in order for compliant applications to run on future Java releases after the Security Manager is degraded and then removed."

Now I've personally been arguing for not using/depending on the security manager in server side code for a long time. The idea of running potentially untrusted code on your own server always struck me as awkward and something you would not do anyway, even when running multiple applications on a single server instance was still somewhat of a thing.

The TCK and GlassFish use the security manager a lot, so that would have to be removed depending on the final outcome of JEP 411.

Kind regards,

jakartaee-platform-dev mailing list
To unsubscribe from this list, visit;!!GqivPVa7Brio!Lyp8ufQvUPlUW9ft3ojHD_zOf88CmLxVtY8qRin1cfC7UqUS4lu3YAgVd4JfusxqDzQ$

Back to the top