JDK-8328643 : Release Note: The `Subject.getSubject` API now Requires Setting the `java.security.manager` System Property to '`allow`' on the Command Line
  • Type: Sub-task
  • Component: security-libs
  • Sub-Component: javax.security
  • Affected Version: 23
  • Priority: P3
  • Status: Resolved
  • Resolution: Delivered
  • Submitted: 2024-03-20
  • Updated: 2024-09-20
  • Resolved: 2024-08-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 23
23Resolved
Description
The terminally deprecated method `Subject.getSubject(AccessControlContext)` has been respecified to throw `UnsupportedOperationException` if invoked when a Security Manager is not allowed.

When the Security Manager is removed in a future release, the `Subject.getSubject(AccessControlContext)` method will be degraded further to throw `UnsupportedOperationException` unconditionally.

Maintainers of code using `Subject.doAs` and `Subject.getSubject` are strongly encouraged to migrate this code to the replacement APIs, `Subject.callAs` and `Subject.current`, as soon as possible. The `jdeprscan` tool can be used to scan the class path for usages of deprecated APIs and may be useful to find usage of these two methods.

The temporary workaround in this release to keep older code working is to run with  `-Djava.security.manager=allow` to allow a Security Manager to be set. The `Subject.getSubject` method does not depend on a Security Manager but requires the feature be "allowed" due to the `AccessControlContext` parameter.

As background, the changes in this release are to help applications prepare for the eventual removal of the Security Manager. For this release, subject authorization and the `Subject` APIs behave differently depending on whether a Security Manager is allowed or not:

- If a Security Manager is allowed, meaning the system property `java.security.manager` is set on the command line to the empty string, a class name, or the value "allow", then there is no behavior change when compared to previous releases.

- If a Security Manager is not allowed, the system property `java.security.manager` is not set on the command line or has been set on the command line to the value "disallow", then the `doAs` or `callAs` methods invoke an action with a `Subject` as the current subject for the bounded period execution of the action. The Subject can be obtained using the `Subject.current` method when invoked by code executed by the action. The `Subject.getSubject` method cannot obtain the Subject as that method will throw `UnsupportedOperationException`. The Subject is not inherited automatically when creating or starting new threads with the `Thread` API. The Subject is inherited by child threads when using [Structured Concurrency](https://openjdk.org/jeps/462). 

As noted above, maintainers of code using `Subject.doAs` and `Subject.getSubject` are strongly encouraged to migrate the code to `Subject.callAs` and `Subject.current` as soon as possible. 

Code that stores a Subject in an  `AccessControlContext` and invokes `AccessController.doPrivileged` with that context should also be migrated as soon as possible as this code will cease to work when the Security Manager is removed.

Maintainers of code that uses the `Subject` API should also audit their code for any cases where it may depend on inheritance of the current Subject into newly created threads. This code should be modified to pass the Subject to the newly created thread or modified to make use of structured concurrency.
Comments
I re-read the release note. The text starting "To prepare applications ..." has good information and guidance but I think the wording can be improvement. I've made an attempt to re-word. In particular, the 3 points in the last paragraph are split up so that it's clear that there is 3 pieces of guidance here.
28-06-2024
I made the changes as Alan proposed, but probably could use more. I think we can simplify the last few paragraphs and just list the behavior differences if the new methods are used w/o an SM.
27-06-2024
I think it's important to lead with the behavior change. That's what developers/customers will be looking for when they get UOE after upgrading and wonder if they have found a JDK bug. It would be okay to follow it with more context/detail. The guidance is to move to callAs/current. It's not a 1-1 replacement for code that relies on inheritance so have a clear paragraph on that would be good.
21-06-2024
Your suggested text is clearer. While the title is only about Subject.getSubject, this release note is for the whole "alternative implementation" and I'd like to keep the descriptions on it. I'd like to insert the 2 "- If a SecurityManager..." paragraphs after your suggested first paragraph.
17-06-2024
I think this RN will need to be re-worded, here's a suggestion for something more direct: "The terminally deprecated method Subject.getSubject(AccessContextContext) has been re-specified to throw UnsupportedOperationException if invoked when a Security Manager is not allowed. This method will be degraded further in a future release to throw UnsupportedOperationException unconditionally. Maintainers of code using Subject.doAs and Subject.getSubject are strongly encouraged to migrate this code to the replacement APIs, Subject.callAs and Subject.current, as soon as possible. The jdeprscan tool can be used to scan the class path for usages of deprecated APIs and may be useful to find usage of these two methods. The temporary workaround in this release to keep older code working is to run with -Djava.security.manager=allow to allow a Security Manager be set. The Subject.getSubject does not set a Security Manager but requires the feature be "allowed" due of the AccessControlContext parameter.
17-06-2024