ComponentSpace

Forums



SAML InResponseTo don't match


SAML InResponseTo don't match

Author
Message
jstudzinski
jstudzinski
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)

Group: Forum Members
Posts: 5, Visits: 94
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?
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
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 <PartnerIdentityProvider>.
However, it's better to avoid the issue by not submitting multiple SAML authn requests.

Regards
ComponentSpace Development
JosephNewton
JosephNewton
New Member
New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)

Group: Forum Members
Posts: 5, Visits: 41
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.




ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
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 [email protected].
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?



Regards
ComponentSpace Development
GO


Similar Topics


Execution: 0.000. 4 queries. Compression Enabled.
Login
Existing Account
Email Address:


Password:


Select a Forum....












Forums, Documentation & Knowledge Base - ComponentSpace


Search