Can you try recording the challenge and the answer in each round and then recalculate them in a plain single thread standalone program to verify if the answers are still the same? (Hopefully this calculation is deterministic).
--Weijun > On May 2, 2024, at 4:18 PM, Chris Marshall <oxbow_la...@hotmail.com> wrote: > > 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 >> >>
