On Thu, 4 Nov 2021 22:11:41 GMT, Weijun Wang <wei...@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

Reply via email to