Design and implement replacement for PolicyContext about authorization HOT 6 OPEN

the application server must prevent the methods of the PolicyContext class from being called from calling contexts that are not authorized to call these methods

The API of the class could be reduced to only support unprotected methods

First of all, thanks for your input.

I think there's not going to be any distinction between protected and unprotected methods. The entire notion of protected methods was based on a trusted Application Server (trusted by whoever operated that AS), running a number of untrusted, or less trusted applications. These less trusted applications could also potentially be hostile against each other (e.g. they would be operated by several distinct owners who were all distinct from the AS owner).

The role of the Application Server in this has never really come to be. It would hold in shared hosting perhaps, but this never took off for Java, and where it did, containers and virtual PCs were used instead.

Nowadays, the framework is truly used as a framework, and not as a "web server operation system". This means the owner of the Jakarta EE implementation is the same as the owner of the application itself using it. There is no need to protect oneself against potential malicious intent at this level. This very realisation was an important factor (see the JEP) in deprecating the security manager itself.

from authorization.

Well I'm not particulary calling for splitting the interface, I just see it at as one option. At least giving the applicaiton server means of owning policy context data and controlling its modification would be sufficient and that can be solved by delegate.

There is no need to protect oneself against potential malicious intent at this level.

I do see the fact that any client code (or its dependencies) can execute any PolicyContext method at any time a potential problem.

Up to EE10 it is possible to say that SecurityManager should be enabled for correct behaviour in this regard, there will be no such option with EE11 onwards.

from authorization.

I do see the fact that any client code (or its dependencies) can execute any PolicyContext method at any time a potential problem.

It's the reverse actually; the fact that its dependencies cannot do so is a potential problem. A diverse set of libraries (e.g. things like Exousia in Tomcat) would have to resort to application server / runtime specific code to obtain the required instances to do what it needs to do.

Also note that this ship has long sailed; already implementations can override, provide alternatives, specialisations, interceptors and decorators for similar code using CDI in Jakarta Security (and this is by design).

Thinking it is a problem, is old-world thinking. It's the same thought pattern that said that authentication mechanisms should be installed in an application server directory, using a proprietary mechanism, away from the application. Same for data sources and some other resources.

This line of thinking made some sense when the application server was thought to be running untrusted applications, but this (as mentioned above) never happened.

Up to EE10 it is possible to say that SecurityManager should be enabled for correct behaviour in this regard,

IMHO it's the wrong behaviour, and that's why the SecurityManager was deprecated for removal. Jakarta EE 11 will have the right behaviour; not depending on protecting ones own code against ones own code. It's not for nothing almost no installations run with the security manager enabled.

If you need to protect applications against other applications the (docker) container and the virtual PC (Xen, VMware and such) are MUCH stronger alternatives.

If you have untrusted dependencies in your dependency chain you likely have other problems already. Trusting on the security manager in many cases is a false sense of security.

from authorization.

In the current state of things, it doesn't make much sense to support any policy mechanism in any Jakarta APIs. Since the Scuritymanage will be gone, each runtime would have to implement a replacement. It's just too much work to design a new API to support this and also to implement it in implementations.

I think a better and potentially even safer approach to implementing security policies is to use a Java agent, which would instrument any Java code and can apply custom policies anywhere, not only where some security manager is used. There are already existing solutions that do this in a general way, and implementations can provide their own implementation-specific agents.

from authorization.

If you are looking for a Policy implementation, I have a high scaling, implementation here: https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java

It's a shame that OpenJDK is removing support for Authorization. Authorization is such a core element of our software that we are unable to remove it, the only viable plan we determined is to maintain a downstream fork of OpenJDK that retains sufficient functionality to support Authorization. It's not possible to replace Authorization without some support from low level platform hooks, we looked into using Agent's, we concluded it's easier to maintain existing code in a downstream fork. We can't call it Java, but who cares, as long as it works.

We also have tools to generate policy files, we apply the principal of least privilege, it's much simpler to reason about what functionality you need, than to determine the functionality you want to prevent.

With the right tooling, it's actually not hard to maintain, but I understand that OpenJDK would have had to continually hand edit their test policy files and that must be painful.

from authorization.

It's a shame that OpenJDK is removing support for Authorization.

What they are essentially doing is removing code level security.

Specifically for Jakarta EE the application server code was more privileged than the code of the applications that were executed on it. The AS was kinda like an OS in that regards.

But this came at a great complexity cost, and when you are deploying the AS + embedded app as one unit (hollow jar, fat jar, like spring boot), and especially when you are using containers (such as docker) and virtual servers (such as VMware or Xen) with that, the entire concept of code-level security becomes much less important to even totally unimportant.

from authorization.