There is no service provider pending a SAML response. at ComponentSpace.Saml2.SamlIdentityProvider.SendSsoAsync

SAML for ASP.NET Core
1

Hi,
We have a service provider web farm and an identity provider web farm (which will be replaced by third parties). When a request is initiated from the service provider to the IDP. IDP after user validation throws an exception while executing the below line of code.
_samlIdentityProvider.SendSsoAsync(userIdentity, attributes);
This is a sporadic issue, mostly happening on the first call. This issue occurs only in the load-balancing environment.
I tried to enable the trace and verified the trace. but have not found any clues.
Any help would be appreciated.

2

By default we use an in-memory session store for maintaining SAML session state in support of the SAML protocol.

In a web farm where sticky sessions aren’t employed, you need to store the SAML session state centrally in a database, Redis cache etc.

For more information, please refer to our Web Farm Guide.


3
[quote]
ComponentSpace - 6/17/2023
By default we use an in-memory session store for maintaining SAML session state in support of the SAML protocol.

In a web farm where sticky sessions aren't employed, you need to store the SAML session state centrally in a database, Redis cache etc.

For more information, please refer to our Web Farm Guide.


[/quote]

I use them in inranet site, and we don't validate InresponseTo flag as well. So, do you we still need session store here? if so, why? and what's the abstraction behind SendSsoAsync ? FYI, i use third party IdP and they would know my assertion end point.

Thanks,
Shamveel
4

The SAML response includes an InResponseTo field that’s set to the ID of the SAML authn request. This ID is stored in the SAML session state at the time _samlIdentityProvider.ReceiveSsoAsync is called. Not setting the InResponseTo field for an SP-initiated SSO SAML response is against the SAML specification and in most cases would cause issues at the SP.

Are you saying the SP is within your organization and it doesn’t validate the InResponseTo field? If so, you could call _samlIdentityProvider.InitiateSsoAsync instead of _samlIdentityProvider.SendSsoAsync to treat this as an IdP-initiated SSO which doesn’t require the InResponseTo field or saved SAML session state. However, this is a bit of a hack and I would encourage you to instead store the SAML session state centrally as per my previous reply.