Some background:
We are using the ASP.NET Core middleware component as our one and only external provider for IdentityServer4. If there is a successful sign in from ComponentSpace we delete the session set by ComponentSpace and we create a new one for IdentityServer4 as seen here https://github.com/IdentityServer/IdentityServer4/blob/dev/src/Host/Quickstart/Account/AccountController.cs#L207-L210 and since we intend on running IS4 in an web farm, we want to make sure we arent missing any loose ends.
The docs say for the Distributed Cache Session Store: A default implementation stores SSO session data in an IDistributedCache
What is SSO session data exactly? Do we need to worry about this since we immediately sign out HttpContext.SignOutAsync after setting a session with IS4?
The ISsoSessionStore stores SAML session information used to support the SAML protocol.
The IIDCache is used to store SAML assertion IDs to detect SAML assertion replay attacks. This is only used when acting as a service provider.
The ISsoSessionStore is unrelated to the user’s authentication session.
The IIDCache is used to store SAML assertion IDs to detect SAML assertion replay attacks. This is only used when acting as a service provider.
The ISsoSessionStore is unrelated to the user's authentication session.
So if I understand correctly, it might be possible that one of the many 302s that happen during a SSO sign-in flow may result in a load balancer trowing a user over to a different server (say, during the POST with SAML back to the SP) and now when ComponentSpace middleware tries to check ISsoSessionStore for the state it will not have the GUID in memory and it will blow up?
In a web farm, if you’re using sticky sessions, there won’t be an issue using the default ISsoSessionStore.
Otherwise, if you’re not using sticky sessions, you must use a central store for the ISsoSessionStore.
The default implementation of ISsoSessionStore uses an IDistributedCache.
https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.caching.distributed.idistributedcache?view=aspnetcore-2.0
The default implementation of IDistributedCache is MemoryDistributedCache.
https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.caching.distributed.memorydistributedcache?view=aspnetcore-2.0
MemoryDistributedCache only makes sense to use either in a single server deployment or multi-server deployment but with sticky sessions.
You can use dependency injection to specify a different IDistributedCache implementation.
For example, you could use RedisCache or SqlServerCache.
https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.caching.redis.rediscache?view=aspnetcore-2.0
https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.caching.sqlserver.sqlservercache?view=aspnetcore-2.0