DatabaseSSOSessionStore: NO ASP.Net

SAML for ASP.NET
1

Hi,

We are using component space to implement an SSO Idp on a custom solution that does not use ASP.Net! (I have no control over this aspect!)

We are trying to use DatabaseSSOSessionStore:

SAMLController.SSOSessionStore = new DatabaseSSOSessionStore(“SamlConnection”);

But the documentation seems to be sparse. We have observed the following behaviour:

  1. When the logon form is accessed and SAML.HttpContext = new SAMLHttpContext()is present a record is saved into the SSOSessions table automagically
  2. When the above is not present we get the error: ComponentSpace.SAML2.Exceptions.SAMLEnvironmentException: There is no HTTP context.
  3. SAML.HttpContext is static
  4. When 2 users try to logon in quick succession there is cross over of session Id
We have the ability to read and persist the session Id in memory when the logon form is loaded:

but how can we load the session object by the session id at later time?

Warmest wishes,

Ashley

2

The ISSOSessionStore interface which is implemented by the DatabaseSSOSessionStore includes a SessionID property.
The SessionID uniquely identifies a user’s SSO session.
The default implementation of this property uses the HttpSessionState.SessionID property.
This requires ASP.NET sessions to be enabled even though information isn’t stored in the actual ASP.NET session. All that’s used is the HttpSessionState.SessionID.
The ISSOSessionStore.SessionID is used by DatabaseSSOSessionStore to derive a unique key into the database table.
If HttpContext and HttpSessionState aren’t present then this will fail as observed.
SAML.HttpContext, which is a static property used to retrieve the HttpContext, by default retrieves the System.Web.HttpContext.Current property which is also static.
Therefore, being a static property normally isn’t an issue.
If there’s a cross over of session IDs, I suspect there’s some issue with the way the SAML.HttpContext or SAML.HttpSessionState properties have been set.
If you have a different mechanism for distinguishing browser/user sessions and given you’re not using ASP.NET, perhaps it would be better to provide a custom implementation of the ISSOSessionStore.SessionID property rather than relying on HttpSessionState.SessionID.