Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [jca-dev] [External] : Re: Jakarta Connectors removal of Security Manager dependency

JDK 17 and 21 will be the one for Glassfish 8 certification, Jakarta EE 11 is open ended with JDK 17+.

Platform requirement is for containers support execution in a Java™ runtime environment, as defined by the Java Platform, Standard Edition specification, v17 or later (Java SE 17 or later).

Hence my questions on JDK24+.

regards,
Guru

From: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Sent: 27 November 2024 18:20
To: Gurunandan Rao <gurunandan.rao@xxxxxxxxxx>; Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>; jca developer discussions <jca-dev@xxxxxxxxxxx>
Cc: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: RE: [jca-dev] [jakartaee-platform-dev] [External] : Re: Jakarta Connectors removal of Security Manager dependency
 

I thought target for Jakarta EE 11 is JDK 17 and/or 21?

 

--

Steve Millidge
Founder & CEO

 

From: Gurunandan Rao <gurunandan.rao@xxxxxxxxxx>
Sent: 27 November 2024 12:48
To: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>; jca developer discussions <jca-dev@xxxxxxxxxxx>
Cc: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jca-dev] [jakartaee-platform-dev] [External] : Re: Jakarta Connectors removal of Security Manager dependency

 

Hi Steve,

The question is related to EE 11 Platform TCK connector tests with JDK24+.

 

regards,

Guru


From: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Sent: 27 November 2024 17:53
To: Gurunandan Rao <gurunandan.rao@xxxxxxxxxx>; jca developer discussions <jca-dev@xxxxxxxxxxx>; Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Cc: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: RE: [jca-dev] [jakartaee-platform-dev] [External] : Re: Jakarta Connectors removal of Security Manager dependency

 

I don’t know wont that be addressed as part of Jakarta EE 12? Can you raise an issue on the GitHub to capture discussions.

 

--

Steve Millidge
Founder & CEO

 

From: Gurunandan Rao <gurunandan.rao@xxxxxxxxxx>
Sent: 27 November 2024 10:52
To: jca developer discussions <jca-dev@xxxxxxxxxxx>; Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Cc: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jca-dev] [jakartaee-platform-dev] [External] : Re: Jakarta Connectors removal of Security Manager dependency

 

Hi Steve Millidge,

What will be recommended paths for enforcement of Security Permission defined within Connector 2.1 component SPEC for JDK24+?

 

regards,

Guru

 

 


From: Arjan Tijms <arjan.tijms@xxxxxxxxxxx>
Sent: 21 November 2024 15:46
To: jca developer discussions <jca-dev@xxxxxxxxxxx>
Cc: arjan tijms <arjan.tijms@xxxxxxxxx>; Gurunandan Rao <gurunandan.rao@xxxxxxxxxx>; jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>; EE4J Security project <jakarta-security-dev@xxxxxxxxxxx>
Subject: Re: [jca-dev] [jakartaee-platform-dev] [External] : Re: Jakarta Connectors removal of Security Manager dependency

 

Hi,

 

 

 

On Thu, 21 Nov 2024 at 09:57, Gurunandan Rao via jca-dev <jca-dev@xxxxxxxxxxx> wrote:

Question 1:

 

Can the Jakarta Security Authorization API be used by an application server to enforce the default set of permissions specified in the Connector Specification 2.1, without relying on a SecurityManager?

 

Not really no. These two address two opposite types of permissions.

 

Jakarta (Security) Authorization: User level permissions. These consider the code the server is running as trusted, and the (remote) user accessing the server as untrusted.

 

Java SE SecurityManager: Code level permissions. These consider the (remote) code running on a (local) system as untrusted, and the (local) user accessing the application running that code as trusted.

 

Particularly, Jakarta Authorization is about you running a server that want to protect against remote users logging in to that server, while the Java SE security manager is about you running an application that you got from an untrusted source and protecting your own system against that application.

 

 

 

Question 2:

 

Are there Authorization APIs available that can help enforce the SecurityPermission SPI, as defined in the Connector Specification, without the need for a SecurityManager?

 

Not really. You could at most say that the security manager is now always disabled by default, and when the security manager is disabled the connectors get all permissions explicitly in a way.

 

Kind regards,

Arjan Tijms

 

 

 

connector 2.1 annotation: 

 

 

regards,

Guru


From: Gurunandan Rao <gurunandan.rao@xxxxxxxxxx>
Sent: 20 November 2024 18:11
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Brian Stansberry <brian.stansberry@xxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [External] : Re: Jakarta Connectors removal of Security Manager dependency

 

Jakarta EE 11 Platform Specification removes requirement to use a Security Manager  [ https://jakarta.ee/specifications/platform/11/jakarta-platform-spec-11.0-m4#jakarta-ee-security-manager-related-requirements].

 

Connector 2.1 specification violates Jakarta EE 11 Platform specification by stating that  "An application server must provide a set of security permissions for executing a resource adapter in a managed runtime environment. A resource adapter must be granted explicit permissions to access system resources".

 

These specific requirements in Platform EE 11 Spec and Connector 2.1 are conflicting with each other.

 

regards,

Guru

 

 


From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of Brian Stansberry via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Sent: 13 November 2024 23:01
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Brian Stansberry <brian.stansberry@xxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [External] : Re: Jakarta Connectors removal of Security Manager dependency

 

If a spec, xsd etc is discussing behavior that is driven by the Security Manager it seems to me that that behavior is only relevant when there is a working SM in the runtime. Specs may not have explicitly stated that, because it was just understood. This is nothing new as most EE workloads are executed in runtimes without the SM enabled.

 

JEP 486 is saying there won't be a working SM anymore in SE 24, but it's not going to cause calls to the SM APIs to fail. So applications running on SE 24 are working in the same basic situation as those that have been running for decades now in runtimes that don't have the SM enabled. So I don't see a problem here when it comes to specs, xsds etc. Something to clean up in the future, but not a problem now.

 

TCKs are a different matter. If an EE 11 implementation needs to run a particular TCK in order to certify, then there needs to be a way to exclude tests that require an SM. AIUI such tests are being removed from the EE 11 platform TCK.

 

On Wed, Nov 13, 2024 at 1:42AM hantsy bai via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Jakarta EE 11 requires Java 17 as a baseline, but we can not prevent end users from using a newer JDK in their environment. JDK 24 includes a couple of new language features, which are very attractive for developers. And when JDK 24 is released, all Jakarta EE providers should be ready for the new product for Jakarta EE 11.

 

I remember the *removal of the Security Manager* was a task in the initial discussion of Jakarta EE 11.  Now that WildFly/OpenLiberty is aligned with the Jakarta EE 11 core profile,  the Jakarta EE platform profile is not finalized yet, there is still some room to do the cleanup of the Security Manager.

---

Regards,

Hantsy Bai

Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker

GitHub: https://github.com/hantsy

Twitter: https://twitter.com/@hantsy

 

 

On Wed, Nov 13, 2024 at 3:19PM Gurunandan Rao via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Jakarta EE  releases are open-ended, Jakarta EE 11 release minimum Java  SE is  17.

 

 

regards,

Guru


From: Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Sent: 12 November 2024 21:40
To: jca developer discussions <jca-dev@xxxxxxxxxxx>
Cc: Gurunandan Rao <gurunandan.rao@xxxxxxxxxx>; jakartaee-platform-dev@xxxxxxxxxxx <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: [External] : Re: Jakarta Connectors removal of Security Manager dependency

 

Thanks for pointing this out.  It will be important for Jakarta EE 12.  I do not believe it impacts Jakarta EE 11 because Jakarta EE 11 aligns with Java SE 21 and 17, not 24.

 

From: jca-dev <jca-dev-bounces@xxxxxxxxxxx> on behalf of Gurunandan Rao via jca-dev <jca-dev@xxxxxxxxxxx>
Date: Tuesday, November 12, 2024 at 12:47
AM
To: jca-dev@xxxxxxxxxxx <jca-dev@xxxxxxxxxxx>
Cc: Gurunandan Rao <gurunandan.rao@xxxxxxxxxx>, jakartaee-platform-dev@xxxxxxxxxxx <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] [jca-dev] Jakarta Connectors removal of Security Manager dependency

Hi, IMO, due to removal of Security Manager in JDK24, there will be requirement of a new release of Jakarta Connectors for JEE 11. Connector 2.1(EE10) Spec reference to Permissions: https://jakarta.ee/specifications/connectors/2.1/jakarta-connectors-spec-2.1#security-permissions

Hi,

IMO, due to removal of Security Manager in JDK24, there will be requirement of a new release of Jakarta Connectors for JEE 11.

 

Connector 2.1(EE10) Spec reference to Permissions:

https://jakarta.ee/specifications/connectors/2.1/jakarta-connectors-spec-2.1#security-permissions

 

Connector 2.1(EE 10) SPEC references to Permission - https://jakarta.ee/xml/ns/jakartaee/connector_2_1.xsd

 

Connector TCK will have to remove https://github.com/jakartaee/platform-tck/blob/b3ba0618bb2a201d26741ca13145cbfdcfa7c1fd/connector/src/main/java/com/sun/ts/tests/connector/permissiondd/Client.java tests that depend on security manager.

 

 

regards,

Guru

 

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

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

 

 

--

Brian Stansberry

Principal Architect, Red Hat JBoss EAP

WildFly Project Lead

He/Him/His

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


Back to the top