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

[Weijun Wang]

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

When we introduce a new API, we hope it always works as specified. In this case, it should work with both the `ThreadLocal` and `AccessContolContext` mechanisms.

In my understanding, to work with the `AccessContolContext` mechanism, this `Supplier<Subject>` must be wrapped into some kind of `Subject`. This could be weird.

Now, if we do this inside JDK, then `callAs(Supplier,Callable)` will create this weird subject and then call `callAs(Subject,Callable)`, and then `current()` will inspect if the subject is in this style and if so fetch the real inner subject and return it. This will be transparent to users.

Otherwise, users would need to apply this trick themselves. They need to create this weird subject and call the usual `callAs`. Inside the action, they do the same inspection and fetch the real subject. They can either use this subject directly, or, if the final consumer of the subject is something they can not control (For example, the JGSS-API `GSSContext::initSecContext` searches for Kerberos tickets in subject), they would have to call `callAs` again with this real subject. That's what I meant `callAs` in `callAs`.

That's all I can think of now.

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

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