I am working on an IdP-initiated single sign-on integration. We are the IdP.
The service provider has two cookies for the duration of the session. On our initial connection to their assertion URL their response sets both cookies on the requesting browser. But our subsequent requests to them are only including one of the cookies. We are missing the session cookie, which is the first one set.
The SP says:
“My guess from this is that when you submit the request initially, it’s not coming from the browser itself, but coming from the library you’re using in .NET directly. SAML states that the user request must come from the browser which can then be used to invoke session state. Is there a way to get out the Base64 SAML and then place that into a hidden form on the browsers page and auto POST that to our endpoint? Based on what I am seeing in the logs, I think this is how we should proceed.”
We are sending the SAML response using IdentityProvider.SendSAMLResponseByHTTPPost
Is what they suggest reasonable? Or is there another way to send the session cookie?
Thanks!
You’re using the HTTP-Post binding so the SAML response will be sent via the browser to the SP.
I suggest using the browser developer tools to capture the network traffic to determine what’s happening to the session cookie.
IdentityProvider.SendSAMLResponseByHTTPPost is part of our low-level API.
Our recommendation is to use the high-level API’s SAMLIdentityProvider.InitiateSSO or SAMLIdentityProvider.SendSSO as these APIs are easier to use and are configuration driven.
The ExampleIdentityProvider project under the Examples\SSO\HighLevelAPI\WebForms demonstrates its use.
This won’t have any impact on the SP’s cookies.
I suggest using the browser developer tools to capture the network traffic to determine what's happening to the session cookie.
IdentityProvider.SendSAMLResponseByHTTPPost is part of our low-level API.
Our recommendation is to use the high-level API's SAMLIdentityProvider.InitiateSSO or SAMLIdentityProvider.SendSSO as these APIs are easier to use and are configuration driven.
The ExampleIdentityProvider project under the Examples\SSO\HighLevelAPI\WebForms demonstrates its use.
This won't have any impact on the SP's cookies.
My certificate and password are both stored in a SQL database. I don't see a way in the high-level example to load a certificate outside of the saml.config file. This is why I went with the low-level. Is there a way to do this with the high-level API?
I have used Fiddler to capture the network traffic. I can see both cookies being set initially but my requests after that have only the first cookie. There are no errors aside from the service provider rejecting the SSO because of the missing cookie.
I suggest using the browser developer tools to capture the network traffic to determine what's happening to the session cookie.
IdentityProvider.SendSAMLResponseByHTTPPost is part of our low-level API.
Our recommendation is to use the high-level API's SAMLIdentityProvider.InitiateSSO or SAMLIdentityProvider.SendSSO as these APIs are easier to use and are configuration driven.
The ExampleIdentityProvider project under the Examples\SSO\HighLevelAPI\WebForms demonstrates its use.
This won't have any impact on the SP's cookies.
My certificate and password are both stored in a SQL database. I don't see a way in the high-level example to load a certificate outside of the saml.config file. This is why I went with the low-level. Is there a way to do this with the high-level API?
I have used Fiddler to capture the network traffic. I can see both cookies being set initially but my requests after that have only the first cookie. There are no errors aside from the service provider rejecting the SSO because of the missing cookie.
[/quote]
For test purposes I put the certificate on my local machine and used the high-level API. I'm having the same issue - both cookies are set but then only one is sent back in subsequent requests.
For certificates stored in a database, you have a couple of options.
You can implement either the ICertificateManager or ICertificateLoader interface and this gives you complete control over the loading of the certificates including from where they’re loaded (eg your database). Both interfaces and base classes are under the ComponentSpace.SAML2.Certificates namespace.
A better option, assuming you’re storing the SAML configuration as well as the certificates in a database, is to implement the ISAMLConfigurationResolver interface which is under the ComponentSpace.SAML2.Configuration.Resolver namespace. You’ll find examples of implementing this interface in the ExampleServiceProvider and ExampleIdentityProvider Global.asax classes. The certificates would be accessible through the LocalCertificateString and PartnerCertificateString properties of the configurations.
I don’t think the missing cookie is related to the SAML SSO or how you are loading certificates etc.
If the cookie is missing, is there a domain name or path difference preventing the presentation of the cookie?
Is the cookie marked as secure and you’re using an HTTP vs HTTPS connection?
If you’re not sure what’s going on, you’re welcome to email the .saz file to support@componentspace.com and we can take a look.
Thanks for the information on the certificate.
I’ve discovered that if I set the SAML link to open in a new tab the session cookie is included correctly. The problem only happens when I set it to open within an iFrame on my page (which is the goal). My hypothesis right now is that there is a conflict with our own session cookie, so I don’t think it’s related to the SAML.
Thanks for the update.