Our client is running into this issue, I have yet to reproduce it and they can’t either:
“The SAML message InResponseTo _aee4e0fe-2bd2-4992-bf6b-25c945aa9737 doesn’t match the expected InResponseTo _a7d7b51b-1f74-4ca7-9d9b-9208f8e5995d”
Thoughts on a fix besides disabling security in the app?
This can occur if two SAML authn requests are submitted. For example, the user clicks a button twice which initiates SAML SSO twice.
We expect a response to the second authn request but the identity provider responds to the first authn request.
You can disable the check by setting DisableInResponseToCheck to false for the .
However, it’s better to avoid the issue by not submitting multiple SAML authn requests.
We’ve run into a similar issue of duplicate authorization requests, where the first initiation of SSO is caused by the browser (Chrome in this instance) attempting to pre-render resources prior to the second (actually intentional) request is sent.
We verified this as the cause by setting a breakpoint on the line containing a call to the ISamlServiceProvider’s InitiateSsoAsync method, which is hit twice in quick succession, first when the url is typed into the address bar and then a moment later when the user hits enter.
It’s awkward to reproduce as the browser seems to attempt to pre-render a url at most once every five minutes and it doesn’t write an entry to the network tab in dev. Chrome also doesn’t provide any way to differentiate between pre-rendering requests and user initiated requests that I’m aware of (see https://stackoverflow.com/questions/9852257/http-header-to-detect-a-preload-request-by-google-chrome).
Do you have any advice on how to deal with this? I don’t think it’s reasonable to expect all of our clients to disable pre-rendering in their browsers.
There is the DisableInResponseToCheck setting as mentioned above but it would be better to avoid the issue in the first place if possible.
From the SO link it doesn’t sound like the two HTTP Gets will be different but it would be worth checking.
Please capture the HTTP traffic using Fiddler and send the .saz archive file to support@componentspace.com.
Is the intention to immediately initiate SSO when the user browses to the URL without any further intervention (eg clicking a button)?
I’m just wondering if the issue could be avoided with a small redesign of the UI.
Otherwise, could your application keep track of whether there’s a pending SSO request and not call InitiateSsoAsync again until a SAML response is received or a small timeout period elapses?