A possible JEP to replace SecurityManager after JEP 411

[Sean Mullan]

Ok, thanks for some clarification on the proposal.

How many applications currently depend on the SM for this type of usage? 
What other alternate models have you considered?

In general, I think authorization is best done at a higher layer within 
the application and not via low-level SM callouts. Authorize the subject 
first and if not acceptable, prevent the operation or API from being 
called in the first place. Once the operation is in motion, you have 
already taken a greater risk that something might go wrong.

 > I hope this clarifies things. Like I said, "no" is an acceptable
 > answer for us but I would be remiss if I didn't ensure that the "no"
 > was based on an accurate understanding of what we are proposing, so
 > hopefully this helps.

It does help, but not enough to change my previous stance.

--Sean

On 4/8/22 9:03 AM, David Lloyd wrote:
> Instead the API would exist to give containers and applications an
> extra layer of authorization which does not exist today.
> Hypothetically speaking, if even one authorization check is retained,
> then that is more than would exist if the API were removed. There
> would be no expectation that usage of this API conveys any kind of end
> to end security, and this would be explicitly conveyed in the API
> documentation.