We’re migrating to SQL Server-baked SSO sessions. We have a few questions:
How should we go about adding columns to the SSOSessions table in SQL Server? We would like to add a user id column, among other things. Are there hooks that the ComponentSpace library invokes when it adds or updates a row in that table?
Is there an API method that we need to call to delete sessions from SQL Server, or should we simply delete rows from the database manually?
The documentation states that the SessionObject stored in the database is an opaque array of bytes. Is there nevertheless a way to decode it and retrieve information such as the partner service provider name/id for a given session?
Hi Franz Are you storing your ASP.NET sessions in SQL Server or just the SAML SSO sessions? If you’re storing the ASP.NET sessions in SQL Server then you don’t need to do anything special for the SAML SSO sessions as these will be stored along with the rest of the ASP.NET session data in the ASP.NET session database. The DatabaseSSOSessionSTore class doesn’t support updating additional columns in the table. You can provide your own implementation of the ISSOSessionStore interface which gives you complete freedom to add additional columns etc as required. Your implementation could extend AbstractSSOSessionStore or AbstractDatabaseSSOSessionStore for convenience. AbstractDatabaseSSOSessionStore includes a DeleteExpired method which deletes all expired entries from the table. However, this is not called automatically. Your application may call this or you can handle maintenance of the table in some other manner. The SessionObject should be treated as an opaque object. We prefer not to expose its contents as this is internal to our library.
Hi Franz Are you storing your ASP.NET sessions in SQL Server or just the SAML SSO sessions? If you're storing the ASP.NET sessions in SQL Server then you don't need to do anything special for the SAML SSO sessions as these will be stored along with the rest of the ASP.NET session data in the ASP.NET session database. The DatabaseSSOSessionSTore class doesn't support updating additional columns in the table. You can provide your own implementation of the ISSOSessionStore interface which gives you complete freedom to add additional columns etc as required. Your implementation could extend AbstractSSOSessionStore or AbstractDatabaseSSOSessionStore for convenience. AbstractDatabaseSSOSessionStore includes a DeleteExpired method which deletes all expired entries from the table. However, this is not called automatically. Your application may call this or you can handle maintenance of the table in some other manner. The SessionObject should be treated as an opaque object. We prefer not to expose its contents as this is internal to our library.
[/quote]
Hi!
Thanks for the response.
Regarding SessionObject being opaque: OK, no problem.
Regarding adding columns to the SSOSessions table: I was probably not very clear. Here are some details about what we're ultimately trying to achieve:
We have a number of service providers written with various stacks (PHP, node.js, ASP.NET, Ruby, etc.). Historically these applications all had their own login system and maintained their own user sessions (e.g. in Redis).
We're now migrating these applications to use SSO. For this, we've written an identity provider using ASP.NET MVC and ComponentSpace's SAML library, and all service providers have been modified to initiate and receive SAML requests. For redundancy, multiple instances of this identity provider are running simultaneously (i.e. we have a farm of them).
Due to the size and complexity of the service providers, it is impractical to refactor them to all use the same session store. They continue to each maintain their own user sessions using various technologies.
Here is what we are trying to achieve: We need to be able to force-logout any user from all service providers it has sessions on. That means instructing those service providers to delete their session corresponding to that user. We are doing this via a custom (non-SAML) HTTP endpoint implemented in each SP. That means we are transitioning to using SAML for SSO only, no longer for SLO.
This is why we need additional columns (a global unique user ID in particular) in the SSOSessions table: We need to be able to find all "active" sessions of a logged user in order to send logout notifications to all service providers he was connected to.
Hi Franz Thank you for the additional details. To include a GUID column, you would need to implement ISSOSessionStore as previously mentioned. As an alternative approach, you could store the GUIDs in a separate table rather than using the SAML SSO session table. This might make more sense in that the SAML SSO session table supports SAML SSO and the GUID is for your non-SAML logout support.
Hi Franz Thank you for the additional details. To include a GUID column, you would need to implement ISSOSessionStore as previously mentioned. As an alternative approach, you could store the GUIDs in a separate table rather than using the SAML SSO session table. This might make more sense in that the SAML SSO session table supports SAML SSO and the GUID is for your non-SAML logout support.
[/quote]
Hi,
Thanks for your answer.
We decided to inherit from AbstractSSOSessionStore and reimplement Load() and Save(). That works perfectly.
One last question if you don't mind:
Beside our IdP farm, we have an "admin" app that acts as a service provider. Until now it used our own cookie-based SAML SSO session store, but using cookies prevents us from forcing a logout for a particular user: as long as they have the cookie in their browser, their SSO session exists and they can use the admin app; there's nothing we can do except awkwardly attempt to delete his cookie. So we're naturally inclined to use a simple server-side persistence, namely the DatabaseSSOSessionStore provided by the ComponentSpace library (or our own that inherits from AbstractSSOSessionStore).
The question: Can we use the same session store (i.e. the same table in the same database) for the IdP and this service provider? Does this make any sense?
Hi Franz Yes, you could use the same table for both applications (IdP and SP). The opaque session data are different object types for identity provider vs service provider data. In our AbstractDatabaseSSOSessionStore, we combine the session ID and the object type to make the SessionID column value to ensure separation.