Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v3]

[Peter Firmstone]

Can this change be documented along with others planned in the new JEP 
so these changes are easier to track?

There's no mention of this change in the bug id.

We've placed all future development on hold in software that depends on 
Java's Authorization API, (apart from bug fixes), while we figure out 
how to manage changes brought about by JEP411.

Thank you.

Peter.

On 8/03/2024 8:31 am, Peter Firmstone wrote:
> Sent from my iPhone
>
>> On 8 Mar 2024, at 1:35 am, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> On 3/7/24 7:35 AM, Peter Firmstone wrote:
>>> Good Evening,
>>> Just noticed the comment below, this is a breaking change.
>>> Recalling earlier discussions on this list about the removal of the existing Authorization API post JEP411, it was going to be assigned another overarching JEP.
>> Yes that JEP is eventually coming in the near future.
>>
>>> Can we have the entire API destructed in one swift action? That is, all API marked for removal under JEP411 should now throw UnsupportedOperationException? Keeping the API around as unsupported operation would also allow us to maintain a fork where the API remains functional, without breaking compile time compatibility with Java, while we figure out how to migrate our software over the longer term.
>> The next major step is to remove support for the Security Manager (SM) from the JDK. However, the deprecated for removal APIs will not be removed as part of that - they will be retained and removed at some later time. Some APIs will be degraded to throw UnsupportedOperationException but others (such as AccessController.doPrivileged) will be degraded to behave as if an SM had not been enabled.
>>
>> JAAS is a special case in that it has dependencies on the deprecated SM APIs for uses cases that don't always require the SM to be enabled. Thus, as described in JEP 411, we introduced new replacement APIs (Subject.callAs and Subject.current) in JDK 18 (4 releases ago). Applications depending on JAAS for authentication or authorization cases that do not require an SM should be migrating to these replacement APIs themselves.
>>
>> --Sean
> Should, when possible.  Our software is deeply integrated with the deprecated Authorization API, we've determined it's not possible.  Our only choice is to fork, so I'd definitely prefer the API to remain.  Also if functionality can be removed rather than degraded, that will make it easier to patch in replacement functionality.
>
> Thank you,
>
> Peter.
>
>
>
>
>>> Thank you for retaining Java's Authorization API in Java 21 LTS.
>>> Regards,
>>> Peter.
>>>>>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.