On Thu, 28 Oct 2021 19:34:21 GMT, Weijun Wang <wei...@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

Reply via email to