Re: JEP 411: Documentation on the new way to establish TLS connections

[Alan Bateman]

On 04/06/2021 05:22, Peter Firmstone wrote:
Could someone please advise the recommended way now to preserve the 
Subject in Executors to establish a TLS connection?


I think the primitive you are looking for is scope local variables. It's 
still in the exploration phase but there is a draft JEP [1]. I'm quite 
sure that if we did this 20 years ago then Subject.doAs and friends 
would be different.


-Alan

[1] http://openjdk.java.net/jeps/8263012

Re: JEP 411: Documentation on the new way to establish TLS connections

[Peter Firmstone]

Don't bother replying.

I found that it is actually on the TODO list.

https://bugs.openjdk.java.net/browse/JDK-8266592

I've had enough now anyway, there is no fixing this mess.

Sayonara.


On 4/06/2021 2:22 pm, Peter Firmstone wrote:
Could someone please advise the recommended way now to preserve the 
Subject in Executors to establish a TLS connection?


I am unable to find the documentation.

We use Executors and we preserve the calling Subject across them, to 
use for authentication our TLS endpoints.


This is now deprecated in Java 17, because it uses AccessController 
and AccessControlContext  methods.


I would like to do this in a way that's not deprecated?

Just wondering if anyone has any suggestions?

Ron mentioned on Reddit this morning that there are no new API's being 
developed.


https://bugs.openjdk.java.net/browse/JDK-8267108

Is the assumption that the JDK will be a single user process, so the 
subject just needs to be stored in a Static variable and accessed from 
there instead?


Just wondering what the use case scenario is?

This really sux for us, because we authenticate TLS connections, then 
we run the users with their calling Subjects.


Thank you.

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/FilterX509TrustManager.java 

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/SubjectCredentials.java 



I'm kinda getting the feeling that I'm no longer welcome here.

I recognize that I'm pushing back, and people don't like that, however 
I'm doing so because I am impacted by the recent decision, I can 
assure you I have no personal grudges against anyone.


I'm not looking for assurances that that isn't the case, I just want 
some guidance, I think our whole code base and how we use Java, just 
bit the dust.


--
Regards,
  
Peter.

JEP 411: Documentation on the new way to establish TLS connections

[Peter Firmstone]

Could someone please advise the recommended way now to preserve the 
Subject in Executors to establish a TLS connection?


I am unable to find the documentation.

We use Executors and we preserve the calling Subject across them, to use 
for authentication our TLS endpoints.


This is now deprecated in Java 17, because it uses AccessController and 
AccessControlContext  methods.


I would like to do this in a way that's not deprecated?

Just wondering if anyone has any suggestions?

Ron mentioned on Reddit this morning that there are no new API's being 
developed.


https://bugs.openjdk.java.net/browse/JDK-8267108

Is the assumption that the JDK will be a single user process, so the 
subject just needs to be stored in a Static variable and accessed from 
there instead?


Just wondering what the use case scenario is?

This really sux for us, because we authenticate TLS connections, then we 
run the users with their calling Subjects.


Thank you.

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/FilterX509TrustManager.java 

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/SubjectCredentials.java 



I'm kinda getting the feeling that I'm no longer welcome here.

I recognize that I'm pushing back, and people don't like that, however 
I'm doing so because I am impacted by the recent decision, I can assure 
you I have no personal grudges against anyone.


I'm not looking for assurances that that isn't the case, I just want 
some guidance, I think our whole code base and how we use Java, just bit 
the dust.


--
Regards,
 
Peter.