The OpenJDK Quality Group is promoting the testing of FOSS projects with OpenJDK builds as a way to improve the overall quality of the release. This heads-up is part of a regular communication sent to the projects involved. To learn more about the program, and how-to join, please check here.

Subject.getSubject API Requires Allowing the Security Manager

In JDK 17, as announced in JEP 411, the Security Manager was deprecated for removal. As part of that change, several Security Manager APIs were deprecated for removal, such as AccessControlContext. The Subject::doAs and Subject::getSubject APIs depend on Security Manager related APIs even though they do not require a Security Manager to be installed to use them. These APIs are important when you want to write secure applications that authorize subjects and perform sensitive operations based on their credentials.

As of JDK 23, to help applications prepare for the eventual removal of the Security Manager, subject authorization and the Subject APIs’ behavior depend on allowing the Security Manager:

• If 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 compared to previous releases.
• If 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, invoking the Subject.getSubject method will throw UnsupportedOperationException.

Yet, running an application with -Djava.security.manager=allow to allow setting a Security Manager is a temporary workaround to keep older code working. Since JDK 18 there are new Java Authentication and Authorization Service (JAAS) APIs that do not have dependencies on Security Manager APIs:

• Subject::callAs is a replacement for Subject::doAs,
• and Subject::current is a replacement for Subject::getSubject.

Maintainers of code using Subject.doAs and Subject.getSubject are strongly encouraged to migrate their code to the replacement APIs, Subject.callAs and Subject.current, as soon as possible. For example, using the deprecated APIs to perform work as a particular Subject required getting the AccessControlContext object first:

Subject s1 = new Subject();
Subject.doAs(s1,
    (PrivilegedExceptionAction<Void>)() -> {
        AccessControlContext acc = AccessController.getContext();
        Subject s2 = Subject.getSubject(acc);
        return null;
});

While with the new APIs you just invoke method current() on the Subject:

Subject s1 = new Subject();
Subject.callAs(s1, () -> {
    Subject s2 = Subject.current();
    return null;
});

The jdeprscan tool scans a JAR file for usage of deprecated API elements and is helpful to find code using these methods. Additionally, consider migrating code that stores a Subject in an AccessControlContext and invokes AccessController.doPrivileged with that context as soon as possible. Such code will cease to work when the Security Manager is removed.

More Details

This is a summary, for more details make sure to read the JDK 23 release notes.