Our environment is AKS containers behind an nginx controller, with nginx configured for cookie based session affinity. In the ASP.NET application sessionState is enabled and uses “InProc”.
The problem that we are seeing is that when a new request comes in, an affinity cookie is created but then, when I call InitiateSSO the response is often received by one of the other container instances, and we get an error as follows:
An SP-initiated SAML response from http://wherever/adfs/services/trust was received unexpectedly.
No such issues in IP initiated, thankfully.
So i’m looking to find out if there is some config i can use to instruct component space to forward along the affinity cookie during the SP initiated flow, so that the saml response will end up routing back to the same ASP.NET application that initiated the request, or something like that.
Or, and i fear this might be the case, do i need to move to an out of process saml session state storage scheme like DatabaseSSOSessionStore, in order to support stateless containers?
Thanks
roger
Hi Roger,
We use a SAML_SessionId cookie to access SAML session state that by default is stored in memory. If the SAML response isn’t processed by the same instance that sent the SAML authn request, we won’t have access to the SAML session state and this error will occur.
In some clustered environments can be configured to use sticky sessions (aka session affinity). This means the requests will be routed to the original instance. If this isn’t possible or desirable, you’ll have to use a central repository (eg DatabaseSSOSessionStore as described in the Developer’s Guide).
If your environment is already setup for sticky sessions using an affinity cookie, I suggest capturing the network traffic to determine whether there’s an issue with this cookie not being returned to/sent by the browser. It’s not something that has to be configured in the SAML library.