Authorization layer API and low level access checks.

[Peter Firmstone]

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.

The advantages of being able to address issues with Permission 
implementations and customise, for example,  by providing a replacement 
for SocketPermission, that doesn't call DNS, and allows wild cards for 
subnets, would be significant for the simplification of authorization.

So developers might hope to be able to implement a significantly 
improved authorization layer for a future version of Java, provided we 
have some basic things like JVM hooks for access checks.

-- 
Regards,
  
Peter Firmstone

On 23/06/2021 7:19 pm, Andrew Dinn wrote:
> OHi Peter,
>
> n 23/06/2021 04:02, Peter Firmstone wrote:
>>  1. StackWalker - Can stack walker be back ported to Java 8?
>
> The right place to ask about this is the jdk8u updates project list. 
> However, you probably don't need to ask there because the answer is 
> almost certainly going to be a very loud no.
>
> JDK8u is in long term maintenance mode. The goal of the updates 
> project for that release is to fix security issues and critical bugs 
> *and nothing else* so that existing deployments remain stable as far 
> as possible. Except when required to meet those goals backporting of 
> new functionality is done only under exceptional circumstances.
>
> The only recent examples of new function backports that I am aware of 
> have involved merging up functionality from downstream releases in 
> order to 1) unify the platform and 2) enable downstream contributors 
> to help to maintain a single, standard release i.e. highly exceptional 
> cases where there was a problem for existing users. Your request, by 
> contrast, is exactly the sort of case that maintainers are trying to 
> avoid -- it will introduce change with no gain and the potential of 
> breakage for the vast majority of users.
>
> If you want to deal with  deployments pre and post removal of the 
> Authorization support that you currently rely on I suggest you 
> consider doing that by using a multi-release implementation and 
> package it using the multi-release jar format. If you don't like the 
> idea of multi-release jars you can still implement a standard jar 
> format solution using a provider model. However, you will still need 
> to build the alternative provider jars using the relevant JDK releases 
> so that different providers can rely on different JDK capabilities..
>
> regards,
>
>
> Andrew Dinn
> -----------
> Red Hat Distinguished Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill
>