Well this was frustrating…
{"timestamp":"2024-04-10 15:02:15.111","level":"DEBUG","thread":"ajp-nio-0:0:0:0:0:0:0:0-8009-exec-111","logger":"org.opensaml.saml.saml2.assertion.SAML20AssertionValidator","message":"No subject confirmation methods were met for assertion with ID 'random id number'","context":"default"}
We received this message for two days straight in our test environment. The Okta Spring Boot setup is VERY simple, and on the Okta end this was working. So let’s just say the error made very little sense. ESPECIALLY since we had another app with the same setup working.
Yeah…
Turns out it wasn’t in the Java code or the Okta setup at all.
In our environment we are trying to proxy our apps one at a time from an old server set to a new server set one at a time so that we can upgrade and migrate apps one at a time.
The servers are already load balanced but we wanted to keep the configuration within the front loading Apache components the same so we did this:
<Proxy "balancer://servercluster-ajp">
BalancerMember "ajp://server1:8009"
BalancerMember "ajp://server2:8009"
...
BalancerMember "ajp://serverx:8009"
</Proxy>
Then each of our application Location tags would have something like this line:
ProxyPass "balancer://servercluster-ajp/contextname"
Well, it seems that since the two destination servers do not sahre the session storage, there is a more than likely chance that we would jump from one end server to the other and lose the session during the process.
So now, to correct for this quickly we are now doing a 1 to 1 match in where traffic is being sent. E.g. server1 on old server set is sent to server1 on new server set.
There is likely a BETTER way of correcting for this or handling the traffic in the first place. However, as these are meant to be temporary and the number of applications on these servers is not that large, this is the direction we are currently going to use.
Feel free to let us know if there is a better short term solution. But just incase anyone else is running into this, you might be able to save yourself 2 days of pain in debugging.