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

[Chapman Flack]

On Thu, 28 Oct 2021 19:34:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Hi, Chap. Thanks for the comment.
> 
> Is it possible you run `callAs` with a "higher level" subject that contains a link to another more dynamic subject? For example, just make your `Supplier<Subject>` a public credential inside. If the caller is not something you can modify, does it work if you call `callAs` inside `callAs`?

I am sorry to be so late in replying. I had initially commented via `security-dev` and I see that comment was added here, and your reply appears in the `security-dev` archives but for some reason never appeared in my inbox. So I will try GitHub's UI this time and see if that goes better.

If I remember right, I had looked years ago at making `Subject` itself more clever to handle this case, but was stymied there because `Subject` is final, which was what drove me to the clever-domain-combiner approach.

The topic arises in a situation where the JVM is embedded into a larger C application, and actions in the larger application, unknown to Java, can change the principals on whose behalf the work is being done. (The changes, at least in the cases that interest me, are not completely _asynchronous_ with respect to Java; they may happen between application downcalls to Java code, or during upcalls from Java back into the app; it is simply that Java doesn't knowingly initiate them.)

There can also be some cost in obtaining the current principal information from the C environment, and of mapping that information into Java `Principal` instances and constructing `Set` representations of those. To eagerly do so at every entry or upcall return is undesirable. To do so only when `current()` is called, as with a `Supplier<Subject>`, would be desirable. (The clever-combiner approach nearly achieves that, as it only spends cycles at the times the combiner is called.)

Naturally, the appeal of integrating with the `Subject` API is to support existing Java code that relies on that API to learn the principals it is acting for. If such code would have to be changed to use the `Subject` in a weird way (such as getting a `Supplier<Subject>` out of a custom public credential and calling `get` on that), that would squander the benefit of an existing API. As the new implementation simply uses a `ThreadLocal`, it would then be simpler to just use a different custom `ThreadLocal` and avoid the `Subject` API altogether. But in that case the entire benefit of an existing known API has been lost.

In your last question, about "`callAs` inside `callAs`", I am not quite sure what you had in mind.

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

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