Authorization layer API and low level access checks.

[Peter Firmstone]

Thanks Dalibor,

I'm not a committer, quite happy to do the work, but I need a sponsor.

I'm currently playing around with a simpler security model, where one 
must escalate privileges with a privilegedCall, designed to be submitted 
to an Executor, which is task / thread confined.

Outside of the privilegedCall, there is no stack walk, because there are 
no privileges, so it is unnecessary, it is represented by a singleton 
unprivileged domain.

At the time the task is decorated with privileges, the caller that does 
so, has its domain recorded, at the time the task is executed, the 
context and Subject are reachable from a ThreadLocal, the stack walk is 
only performed back to the commencement of the task, the Subject and 
domains collected are then available to Guard's to check whether the 
privileged call is authorized to proceed.  The ThreadLocal context is 
reset back to its previous value, by a finally block, when the call returns.

So basically, when you want to make a secure connection, authenticate, 
access files or network, you need to make a privileged call and submit 
it to an executor, or virtual thread, at least that's the current concept.

There is no complexity such as static and dynamic Permissions, or 
whether the Subject is preserved or not, the Subject is always preserved 
in the context, which can be stored for use in other privilegedCall's, 
where it will be combined with the results of the task limited stack walk.

The complexity of Permission's is removed, Guard providers may use 
whatever rule based system they desire, coarse grained, or fine grained, 
the information required to make the decision is available to the guard, 
via an Authorization class.

By default, it would probably be best to provide simple coarse grained 
Guard providers, such that the system could be enabled and used by 
default, after a transition period.

Cheers,
  
Peter.

On 29/06/2021 2:53 am, Dalibor Topic wrote:
> Hi Peter,
>
> Larger changes, such as those that appear to be proposed here, should 
> come with their own JEP. Please see 
> https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html for details.
>
> JEPs help among other things build consensus around ideas. Typically 
> it takes around 6 months from the inception of a release, until the 
> feature set is complete, so that should give you some sense of the 
> timings involved.
>
> It can also be useful to split larger proposed changes into several 
> conceptually distinguished smaller ones, and to build up consensus 
> gradually that way.
>
> cheers,
> dalibor topic
>
> On 25.06.2021 07:59, 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
>>>
>