RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs [v5]

Sean Mullan mullan at openjdk.java.net
Fri Nov 5 17:41:21 UTC 2021


On Thu, 4 Nov 2021 22:11:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal.
>> 
>> In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and `callAs()` is implemented based on `doAs()`. This behavior is subject to change in the future once `SecurityManager` is removed.
>> 
>> User can experiment a possible future mechanism by setting the system property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` method stores the subject into a `ThreadLocal` object and the `current()` method returns it (Note: this mechanism does not work with principal-based permissions).
>> 
>> Inside JDK, we’ve switched from `getSubject()` to `current()` in JGSS and user can start switching to `callAs()` in their applications. Users can also switch to `current()` but please note that if you used to call `getSubject(acc)` in a `doPrivileged` call you might need to try calling `current()` in a `doPrivilegedWithCombiner` call to see if the `AccessControlContext` inside the call inherits the subject from the outer one.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tiny spec change to be the same as CSR

src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java line 69:

> 67:         ServiceCreds creds = null;
> 68:         try {
> 69:             creds = AccessController.doPrivilegedWithCombiner(

Suggest adding a comment here and other places briefly explaining why doPrivWithCombiner is now needed to preserve the SubjectDomainCombiner.

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

PR: https://git.openjdk.java.net/jdk/pull/5024


More information about the security-dev mailing list