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

[Chapman Flack]

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

Ah. Yes, making it work in the current `AccessControlContext` mechanism really probably requires teaching `SubjectDomainCombiner` about it, essentially the pre-JEP-411 approach I had come to. If the principals change, that should not only be reflected in what's returned by `getSubject`, but also in what's returned by `combine` (and potentially used in policy decisions).

Its documentation would then have to be written a bit carefully for the non-`ThreadLocal` case, to clarify that the supplier's `get` method is called not only at uses of `getSubject`, but also at times when the combiner is applied, such as `getContext` and prior to permission checks. (More or less intuitive,anyway: those are the times the `Subject` _matters_.) That would simply amount to exposing a straightforward method for doing what can already be done today, only without the tedious step of implementing a custom combiner.

As a modification to `SubjectDomainCombiner` it could be as simple as changing the instance field to `Supplier<Subject>` and having both `combine` and `getSubject` begin with a `final Subject subject = subjectSupplier.get();`. The constructor that takes a `Subject` would simply store `() -> s` as the supplier.

Adding code to the JEP 411 deprecated components seems a bit of a joyless task, but then it is very little code, and there would then be an API for this use case that would be undisrupted when the deprecated components go away. The extra documentation wording about when the supplier getter is called would, of course, become much shorter and simpler at that point.

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

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