Re: [jakartaee-platform-dev] [External] : Reduce emphasis on security ma

[arjan tijms <arjan.tijms@xxxxxxxxx>]

Hi,

For the specs I’m involved with I’d like to deprecate the security checks using the security manager in this release.

Authorisation has a big problem, since Policy is going to be removed, and Policy is a central class in that API.

I therefore plan to deprecate that usage of it, and will look at introducing a replacement class that client code can use instead of Policy.

Kind regards,

Arjan

On Wednesday, August 18, 2021, Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:

On 8/17/21 10:46 PM, Scott Marlow wrote:

On 8/17/21 2:14 PM, Lukas Jungmann wrote:

Hi,

On 7/29/21 3:51 PM, arjan tijms wrote:

Hi,

The Jakarta Platform has a very strong emphasis on the security manager, especially when it comes to TCK testing. A lot (or everything?) is tested with the security manager enabled, and constituent specs and implementations have to comply with that.

As the security manager has been deprecated for removal in JDK 17, I wonder if we should not start taking the first steps in EE 10 to anticipate for this, even though EE 10 is not targeting JDK 17.

Perhaps we could start with making security manager enabled TCK runs optional?

It looks like this got buried here - have you had a chance to discuss this with Scott (cc'ed), ie through different channel, already?

I think that he tests that specifically require the security manager are under { ejb30/sec, connector, servlet, securityapi }.

I've done quick search over the specs to see the impact there and based on my findings:

- ~90% of usages of security manager are null checks followed by the deprecated for removal call to AccessController.doPrivileged if sm is not null. This in particular applies to following specs:
CDI
Security
Authorization
Mail
Activation
SOAP
XML Binding
XML WS
Batch
Persistence
Validation


- calls to SecurityManager.checkPermission are in:
Authorization
Authentication
Security
XML Binding
REST

- there are also few specs defining custom Permission classes which are not deprecated (yet?) but the JEP mentions that these custom classes may become useless once the SecurityManager goes away in JDK 18+. Does the platform want to follow the JEP and start the process for removing them by deprecating them in the EE 10 or is the preferred solution to wait for now? Applies to:
Authorization
Security
XML Binding
XML WS

thanks,
--lukas

Do we know which JDK classes will definitely be removed along with the security manager?  The TCK doesn't have a good way to deal with missing security manager related classes.

thanks,
--lukas

Kind regards,
Arjan

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@eclipse.org
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!dg74znjhBmn8jZ5FrmxPZx8H-Krvvh1j0v6o293w_B8kx04mdIcrnm8_s1IXoFlyrjw$

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@eclipse.org
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev