ComponentSpace

Forums



SP initiated SAML request does not honor session affinity


SP initiated SAML request does not honor session affinity

Author
Message
rogerr
rogerr
New Member
New Member (7 reputation)New Member (7 reputation)New Member (7 reputation)New Member (7 reputation)New Member (7 reputation)New Member (7 reputation)New Member (7 reputation)New Member (7 reputation)New Member (7 reputation)

Group: Forum Members
Posts: 4, Visits: 21
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
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (3.8K reputation)ComponentSpace Development (3.8K reputation)ComponentSpace Development (3.8K reputation)ComponentSpace Development (3.8K reputation)ComponentSpace Development (3.8K reputation)ComponentSpace Development (3.8K reputation)ComponentSpace Development (3.8K reputation)ComponentSpace Development (3.8K reputation)ComponentSpace Development (3.8K reputation)

Group: Administrators
Posts: 2.7K, Visits: 8.4K
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.  

Regards
ComponentSpace Development
GO


Similar Topics


Execution: 0.000. 4 queries. Compression Enabled.
Login
Existing Account
Email Address:


Password:


Social Logins

Select a Forum....









Forums, Documentation & Knowledge Base - ComponentSpace


Search