Hi,
I have implemented a custom session store which extends AbstractSSOSessionStore.cs. I am able to insert and load the session id from the database. I wanted to know how does component space validate the session id at the SP end matches the session ID which we get once we get redirected from the IDP. (particularly in a web farm scenario)
So I had few questions for the scenario:
1. How would I test if component space is actually validating the session id with the session id I get from the database? (for ex: in my testing on my local env, I deleted the session entry from the db and then attempted login at the idp site but the ReceiveSSO worked fine and I was able to login to the system even though I had no corresponding session ID in DB)
2. What happens when we return null from Load(Type type) method?
3. If I do an iisreset and then login to IDP so on redirection I get the error that the SAML.config file is missing.
Any suggestions would be welcome on how to successfully test this scenario?
The SAML session ID is stored in the SAML session cookie. It uniquely identifies the SAML session for a particular browser instance.
The session ID should be used by the SSO session store to create a key or index to store and retrieve the corresponding SAML session state.
The AbstractSSOSessionStore class includes a SessionID property whose default implementation retrieves the session ID from the SAML session cookie.
This class also includes a CreateSessionIDForType method that combines the SessionID with the type of the session state object to create a unique key. This can be used as the index into the session state store.
Regarding your questions:
1. We don’t validate the session ID as such. We retrieve any existing SAML session state and, if there isn’t, we create a new SAML session state. For some SAML flows, existing SAML state is required and, if it isn’t present, this will result in an exception. For other flows, creating a new SAML session state is ok. For example, for SP-initiated SSO, we save the ID of the SAML authn request sent to the IdP in the SAML session state. When SAMLServiceProvider.ReceiveSSO is called, if SAML session state is present, we check the saved ID against the InResponseTo field in the SAML response. If they don’t match we throw an exception. However, if there’s no SAML session state, we cannot make this check and we effectively treat this the same as if it were IdP-initiated SSO. For most use cases this doesn’t matter.
2. If Load returns null we assume there’s no SAML session state for this session and we initialize new sesson state which will be subsequently saved.
3. The SAML configuration (eg saml.config file) isn’t directly related to the SAML session state. I’m not sure why an iisreset would cause an issue with the saml.config file.
Please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com mentioning your forum post.
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
Please ensure the trace captures a successful SSO followed by the iisreset and subsequent error.
The session ID should be used by the SSO session store to create a key or index to store and retrieve the corresponding SAML session state.
The AbstractSSOSessionStore class includes a SessionID property whose default implementation retrieves the session ID from the SAML session cookie.
This class also includes a CreateSessionIDForType method that combines the SessionID with the type of the session state object to create a unique key. This can be used as the index into the session state store.
Regarding your questions:
1. We don't validate the session ID as such. We retrieve any existing SAML session state and, if there isn't, we create a new SAML session state. For some SAML flows, existing SAML state is required and, if it isn't present, this will result in an exception. For other flows, creating a new SAML session state is ok. For example, for SP-initiated SSO, we save the ID of the SAML authn request sent to the IdP in the SAML session state. When SAMLServiceProvider.ReceiveSSO is called, if SAML session state is present, we check the saved ID against the InResponseTo field in the SAML response. If they don't match we throw an exception. However, if there's no SAML session state, we cannot make this check and we effectively treat this the same as if it were IdP-initiated SSO. For most use cases this doesn't matter.
2. If Load returns null we assume there's no SAML session state for this session and we initialize new sesson state which will be subsequently saved.
3. The SAML configuration (eg saml.config file) isn't directly related to the SAML session state. I'm not sure why an iisreset would cause an issue with the saml.config file.
Please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com mentioning your forum post.
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
Please ensure the trace captures a successful SSO followed by the iisreset and subsequent error.
Thank you for the response. I had few other questions:
1. I guess I don't understand the point of implementing session store if we just create a new session id with any response and it still works? (I would expect it to fail since there is no corresponding entry in DB for that session).
2. I was wondering if it is possible to reject/ throw an exception or something in below cases:
- matching session ID can't be found in DB
- when the requestID does not match if we're able to lookup the session
- We could have treated this as a failure. However, it’s possible for two SAML applications to be within the same domain and therefore share the same SAML session cookie. An application can receive this cookie for the first time and not have any saved SAML session state. In this case, we initialize session state and continue to use the same cookie.
2. If your AbstractSSOSessionStore extension class throws an exception, the SSO will fail and the exception will flow up to the application. This isn’t recommended.