Authorization layer API and low level access checks.

[Peter Firmstone]

One more proposed change inline:

On 26/06/2021 12:58 pm, Peter Firmstone wrote:
>
> Summary of Proposed Changes:
>
>  1. GuardFactory & GuardFactorySpi to provide hooks for authorization
>     checks without SecurityManager or Policy. (Note GuardFactory
>     should never return null and instead return a no-op Guard that
>     hotspot can optimize out.
>  2. Existing Permission implementations to be obtained using
>     GuardFactorySpi implementations, until their removal.  Note that
>     when SecurityManager is stubbed out and Permission implementations
>     are deprecated for removal, these should no longer be provided by
>     default, but instead need to be enabled by entries in the
>     java.security config file, in preparation for their removal.
>  3. JDK code, no longer call Permission implementations directly,
>     instances obtained using GuardFactory, only when enabled in the
>     java.security configuration file.
>  4. Threads (system and virtual) updated to use a singleton
>     *unprivileged* AccessControlContext, instead of inherited
>     AccessControlContext, this is more appropriate for Executors, the
>     original inherited context was designed before Executors were
>     introduced.
>  5. Deprecation for removal of all Permission implementations from the
>     JDK platform.   The existing implementations of Permission
>     introduce unnecessary complexity; they lack sufficient flexibility
>     resulting in a proliferation of Permission grants required in
>     policy files and some make blocking network calls.
>  6. Introduce a system property to change AccessController default
>     behaviour, disable the stack walk by default, but allow it to be
>     re-enabled with a system property, replace the stack walk array
>     result of ProtectionDomains with an *unprivileged*
>     AccessControlContext, the SubjectDomainCombiner can replace it
>     with a, AccessControlContext containing a single element array,
>     containing one ProtectionDomain with Principals.
>  7. AccessController::doPrivileged erases the DomainCombiner by
>     default, deprecate these methods, retain doPrivilegedWithCombiner
>     methods that preserve the SubjectDomainCombiner.   Developers
>     should replace their doPrivileged methods with
>     doPrivilegedWithCombiner
>  8. Deprecate for removal the CodeSource::implies method.
>  9. Give unique ProtectionDomain's with a meaninful CodeSource to Java
>     modules mapped to the boot loader, rather than using a Shared
>     ProtectionDomain with a null CodeSource.
>
     10. Deprecate for removal AccessController::checkPermission and 
AccessControlContext::checkPermission methods.

     11. Undeprecate AccessController, AccessControlContext, 
DomainCombiner, SubjectDomainCombiner and Subject::doAs methods, while 
deprecating for removal methods stated in items above.

> To clarify what an *unprivileged* AccessControlContext is:
>
>     An instance of AccessControlContext, that contains a single
>     element array, containing a ProtectionDomain, with a non null
>     CodeSource, containing a null URL.
>
> Retention of AccessController, AccessControlContext, DomainCombiner 
> and SubjectDomainCombiner and Subject::doAs methods.
>
> Stubbing of SecurityManager and Policy, for runtime backward 
> compatibility. Update ProtectionDomain::implies method, to *not* 
> consult with the Policy.  Note it's possible to get access to the 
> ProtectionDomain array contained within AccessControlContext using a 
> DomainCombiner.
>
> This is backward compatible with existing usages of JAAS and least 
> painful method of transition for all concerned as well as allowing 
> complete flexibility of implementation.
>
> Regards,
>
> Peter Firmstone.
>
> On 25/06/2021 3:59 pm, Peter Firmstone wrote:
>> Thanks Dalibor,
>>
>> Would targeting Java 18 be practical?
>>
>> Also it won't take long to code a prototype, just not sure of the 
>> process.
>>
>> Cheers,
>>
>> Peter.
>>
>>
>> On 24/06/2021 9:30 pm, Dalibor Topic wrote:
>>> On 24.06.2021 04:24, Peter Firmstone wrote:
>>>> Thanks Andrew,
>>>>
>>>> For the simple case, of replacing the SecurityManager stack walk, 
>>>> one could use reflection.
>>>>
>>>> Thank you for also confirming that is not possible (or at least 
>>>> very unlikely) to add a GuardBuilder to Java 8, the proposal is for 
>>>> JDK code to use a provider mechanism, to intercept permission 
>>>> checks, so custom authentication layers can be implemented, this 
>>>> could be accepted in future versions of Java, but not existing. As 
>>>> it is said, there is no harm in asking.
>>>
>>> Generally speaking, adding any public APIs to a platform release 
>>> after its specification has been published, is always going to be a 
>>> very tall order involving the JCP, among other things. It's not 
>>> really worth it, when other technical solutions, such as 
>>> multi-release JARs, already exist, that alleviate the necessity.
>>>
>>> cheers,
>>> dalibor topic
>>>
-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.