Storing SSO sessions in SQL Server

Hi,

Following up on our conversation here: https://www.componentspace.com/Forums/8143/GetPartnerPendingResponse

We used to store SAML SSO sessions in cookies (not just session IDs, but sessions itself). We’re now transitioning to storing sessions into SQL Server and only keeping session IDs in cookies.

Our setup is pretty classic: We have a farm of identity providers (ASP.NET MVC apps) and a number of partner service providers (various stacks).

Following the documentation, we replaced our own cookie-based session store by DatabaseSSOSessionStore:
SAMLController.SSOSessionStore = new DatabaseSSOSessionStore(“System.Data.SqlClient”, “”, “SSOSessions”);

and we created the SSOSessions table via Entity Framework code-first (no problem there).

We also use OWIN cookie-based authentication with the following code:
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
LoginPath = new PathString(“/Account/Login”),
Provider = new CookieAuthenticationProvider
{
// Enables the application to validate the security stamp when the user logs in.
// This is a security feature which is used when you change a password or add an external login to your account.
OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ConnectUserManager, User, int>(
validateInterval: TimeSpan.FromMinutes(30),
regenerateIdentityCallback: (manager, user) => user.GenerateUserIdentityAsync(manager),
getUserIdCallback: (claimIdentity) => claimIdentity.GetUserId())
},
CookieName = “Company_SSO_Authentication”
});

When we log into our IdP, we’re seeing the following SAML trace:
11/14/2017 10:41:08 AM: ComponentSpace.SAML2, Version=2.6.0.15, Culture=neutral, PublicKeyToken=7c51d97b3a0a8ff9, .NET v4.0 build (retail license).
11/14/2017 10:41:08 AM: OS: Microsoft Windows NT 10.0.15063.0, ASP.NET: 4.0.30319.42000, IIS User: , Culture: English (United States)
11/14/2017 10:41:08 AM: The SAML configuration has been set.
11/14/2017 10:41:08 AM: The database SSO session store provider name is System.Data.SqlClient, the connection string is Data Source=localhost;Initial Catalog=;Integrated Security=True and the table name is SSOSessions.
11/14/2017 10:41:08 AM: The SSO session store is DatabaseSSOSessionStore.
11/14/2017 10:41:14 AM: Initializing the SAML environment.
11/14/2017 10:41:14 AM: The SAML configuration has been loaded.
11/14/2017 10:41:14 AM: The local identity provider is .
11/14/2017 10:41:14 AM: The partner service provider is .
11/14/2017 10:41:14 AM: The partner service provider is .
11/14/2017 10:41:14 AM: Loading the configured X.509 certificates.
11/14/2017 10:41:14 AM: Loading the X.509 certificate from the file \Certificates\idp.pfx.
11/14/2017 10:41:14 AM: The X.509 certificate with subject name CN=www.idp.com and serial number has been loaded.
11/14/2017 10:41:14 AM: Caching the local identity provider signature certificate for the default configuration.
11/14/2017 10:41:14 AM: Loading the X.509 certificate from the file \Certificates\sp.cer.
11/14/2017 10:41:14 AM: The X.509 certificate with subject name CN=www.sp.com and serial number has been loaded.
11/14/2017 10:41:14 AM: Caching the signature certificate for the default configuration partner service provider .
11/14/2017 10:41:14 AM: Caching the encryption certificate for the default configuration partner service provider .
11/14/2017 10:41:14 AM: Loading the X.509 certificate from the file \Certificates\sp.cer.
11/14/2017 10:41:14 AM: The X.509 certificate with subject name CN=www.sp.com and serial number has been loaded.
11/14/2017 10:41:14 AM: Caching the signature certificate for the default configuration partner service provider .
11/14/2017 10:41:14 AM: Caching the encryption certificate for the default configuration partner service provider .
11/14/2017 10:41:14 AM: The configured X.509 certificates have been successfully loaded.
11/14/2017 10:41:14 AM: The SAML environment has been successfuly initialized.
11/14/2017 10:41:14 AM: The IdentityProviderSession is being loaded from the database SSO session store.
11/14/2017 10:41:14 AM: Database provider name: System.Data.SqlClient.
11/14/2017 10:41:15 AM: Database command: SELECT SessionObject FROM SSOSessions WHERE SessionID = @SessionID
11/14/2017 10:41:15 AM: Database parameters:
SessionID=a1ff3wxufjagjvy5q24z5ptl:IdentityProviderSession
11/14/2017 10:41:15 AM: Checking if there are any SSO responses pending to partner service providers.
11/14/2017 10:41:15 AM: Identity provider session (a1ff3wxufjagjvy5q24z5ptl) state:
11/14/2017 10:41:15 AM: There are no SSO responses pending to partner service providers.


At this point, we’re logged in but there isn’t any session in the SSOSessions table. We do see a cookie called Company_SSO_Session (as defined in Web.config via ) with value a1ff3wxufjagjvy5q24z5ptl as well as a Company_SSO_Authentication cookie storing the user’s identity.

Our main question is: Why isn’t a session inserted into the SSOSessions table?

Is there some kind of interaction between the SAML library and OWIN authentication that we’re not understanding properly?

Franz

Hi Franz
The log doesn’t show the SAML SSO or the SSO session state being saved to the database.
There should be log entry like:
“The xxxx is being saved to the database SSO session store.”
The SQL update or insert command should also be in the log.
Please send the complete SAML log file as an email attachment to support@componentspace.com mentioning your forum post.
I’d like to see the SAML SSO which should include updating the SSO session state in the database.

[quote]
ComponentSpace - 11/14/2017
Hi Franz
The log doesn't show the SAML SSO or the SSO session state being saved to the database.
There should be log entry like:
"The xxxx is being saved to the database SSO session store."
The SQL update or insert command should also be in the log.
Please send the complete SAML log file as an email attachment to support@componentspace.com mentioning your forum post.
I'd like to see the SAML SSO which should include updating the SSO session state in the database.
[/quote]

Hi,

The SAML trace I included in my first post is the full SAML SSO log file.

As explained (probably insufficiently) in my post, we only log to the identity provider (the web app that presents a login screen), NOT to a partner service provider. We expected that just logging to the identity provider app would lead to a SSO session being created in the database, but it doesn't. We noted though that logging into a service provider DOES lead to the creation of a SSO session in the DB.

We suspect a misunderstanding on our part regarding interactions between OWIN Authentication and the SAML lib. In the case of our IdP, it looks like the session is maybe stored entirely in a cookie instead of in the DB?

Best,
Franz

Hi Franz
Thanks for the clarification.
The SAML SSO session information is unrelated to the authentication mechanism (OWIN etc).
If you’ve configured a database SSO session store then this is used regardless of the authentication mechanism used by the application.
From the trace, it appears the only API call made is to SAMLIdentityProvider.IsSendSSOPending.
This will read the SSO session state but not update it.
If the trace showed a complete SSO interaction then you would see entries where the database is being updated.

[quote]
ComponentSpace - 11/15/2017
Hi Franz
Thanks for the clarification.
The SAML SSO session information is unrelated to the authentication mechanism (OWIN etc).
If you've configured a database SSO session store then this is used regardless of the authentication mechanism used by the application.
From the trace, it appears the only API call made is to SAMLIdentityProvider.IsSendSSOPending.
This will read the SSO session state but not update it.
If the trace showed a complete SSO interaction then you would see entries where the database is being updated.
[/quote]

Hi,

Thanks for the quick answer.

I confirm that there was some confusion on our part. Authenticating into our identity provider is indeed not supposed to lead to the creation of a SSO session in the database. A session only gets created when a service provider initiates a SSO. This is at least our current understanding :)

Best,
Franz

That’s correct. :slight_smile: