sessionState mode

Hi, I recently integrated your v2 SAML component with an asp.net MVC app we have developed. Our application is the Service Provider and the IDP will eventually be a third party app. We have for a few years now run this application with Session state turned off. We don’t use session state and a previous developer found that having it on in our 3 server environment was causing a performance hit. We, therefore, have the following setting in our web.config.



We have so far only deployed the build that integrates your SAML component to a staging test server environment which has 2 servers. I obviously found in development that I have had to turn session state on otherwise I get an exception when I call the component.

I have configured the SAML to use the database tables to hold session state and when session state is turned on in web.config it works.

In order for us to deploy to production, we need to have session state turned OFF. Is there a way to configure the SAML component to work when session state is off ?

thanks in advance
Steve


Hi Steve
The SAML high-level API maintains SAML session information to support the SAML protocol.
By default, the SAML session information is stored in the ASP.NET session.
However, this can be changed by implementing the ComponentSpace.SAML2.Data.ISSOSessionStore interface.
You specify the SSO session store by setting the SAMLController.SSOSessionStore property.
This should be done as part of initialization and prior to any SSO API calls.
Your implementation of ISSOSessionStore should extend AbstractSSOSessionStore.
The InMemorySSOSessionStore is an example implementation that stores SSO session information in-memory although this wouldn’t be applicable in a multi-server web farm environment.
The DatabaseSSOSessionStore stores SSO session information in a database table which can be used in a web farm.
You’ll find these documented in our Developer Guide PDF.
How do you store user-specific information in your application? Is this stored in custom database tables?
If so, the SSO session information could be stored in a database table using DatabaseSSOSessionStore or your own ISSOSessionStore implementation.
How do you identify individual users so you can access user-specific stored information maintained by your application?
The same mechanism could be used to identify the SSO session information specific to the user (browser session).