Hi Alan,

The code is completely unchanged between JDK21 and JDK22; it is using virtual 
threads and StructuredTaskScope in both cases (and also, via a different path, 
platform threads in both cases).

I should perhaps have given a bit more background about why I think that the 
crypto classes are at fault. The UserSRP auth class I linked to sends a message 
to AWS (via an AWS API, ultimately made as an HTTP call) which includes some 
information about the user. Amazon’s server responds (over HTTP) with a 
“challenge” which includes some pieces of information. Using those pieces of 
information plus knowledge of the password, the class I linked to derives an 
answer to the challenge, which is then sent (via HTTP) to AWS. AWS can verify 
that the response could only have been generated by someone with knowledge of 
the password, and they will respond with a valid bearer token, which can be 
used as an authorization header to HTTP calls (to our internal services, which 
can validate the bearer token). In this way, our services can communicate 
between themselves without any passwords ever being transmitted anywhere. In 
the following diagram, the arrows represent HTTP request/responses between us 
and AWS

  Us —-> (info) —> AWS

  Us <—- (challenge) <—- AWS

  Us —> (answer) —> AWS

  Us <— (bearer token | wrong user/pwd) <—- AWS

“Wrong username or password” indicates that the response calculated by the 
linked class is not correct.

I don’t believe (though I’m not an expert, so could be wrong) that this has 
anything to do with javax.security APIs

Chris

On 2 May 2024, at 19:59, Alan Bateman <alan.bate...@oracle.com> wrote:



On 02/05/2024 19:33, Chris Marshall wrote:
:

Last week I upgraded the application to be compiled by JDK22, and run on JDK22. 
Immediately, we started to see failures from within the User-SRP auth code only 
when it was run on a virtual thread from within a StructuredTaskScope. The 
failures are merely that the code appears to have calculated the wrong 
authentication response (i.e. AWS Cognito returns a message to the effect that 
we have the wrong username or password). It is not possible that this could be 
the case, because the same application, using the same username/password combo 
is able to successfully authenticate to AWS Cognito using User-SRP auth from a 
platform thread.

Thanks for reporting a potential issue.

You say that the code was running correctly on JDK 21. Was this in the context 
of virtual threads and using StructuredTaskScope? I'm trying to understand from 
your mail if you were using virtual threads with JDK 21 and whether you were 
using StructuredTaskScope in JDK 21 too.

"wrong username or password" hints that maybe this is some kinda of inheritance 
issue, I'm specifically thinking of the inherit access control context. Would 
it be possible to search the code and libraries that are in use here to see if 
they are using the javax.security.auth.Subject API? It's just a wild guess at 
this point but I think might give some clues as to where inheritance might be 
coming from.

-Alan


Reply via email to