RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs

[Daniel Fuchs]

On Tue, 30 Jan 2024 13:53:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:
> 
>> 347:     @SuppressWarnings("removal")
>> 348:     private Subject getSubject() {
>> 349:         return Subject.current();
> 
> Since `Subject::current` is not deprecated the annotation at line 347 above should be removed.

OK - things seem to be a bit convoluted here and some pieces might be missing. I suspect that what needs to be done is more complicated:

`RMIConnectionImpl` sets up an ACC and calls doPrivileged with that ACC, on the assumption that the subject is tied to the ACC and it can be retrieved down the road from the ACC. `RMIConnectionImpl` has the subject, and the delegation subject too. 

So for `Subject::current` to work here, shouldn't `RMIConnectionImpl::doPrivilegedOperation` use `Subject::callAs` when the security manager is disallowed?

It seems that when `Subject::current` is used, some analysis should be done to verify where the Subject is supposed to come from - that is - how the caller is expecting the subject to reach the callee.

Typically, JMX doesn't use `Subject::doAs` but ties a `Subject` to an `AccessControlContext` and uses `doPrivileged` instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471308151