This project is read-only.

CheckReplayAttack() preventing IdP-Initiated SSO?

Aug 14, 2014 at 9:06 PM
This is my first time using this SAML2 project so this could be due to my ignorance, but is CheckReplayAttack() preventing IdP-Initiated SSO?

I've setup SSO between my site and my IdP and when I launch a traditional IdP-Initiated SSO I get the error message, "Saml20Exception: Received a response message that did not contain an InResponseTo attribute."

I've captured the traffic with SAML Tracer and indeed the InResponseTo attribute is missing. But that's expected during IdP-Initiated SSO, right?

My users are accustomed to launching apps like Salesforce and Marketo directly from the IdP's dashboard of available apps so I need to support IdP-Initiated POSTs without InResponseTo. I'm not seeing any options in the code to bypass CheckReplayAttack() and am thinking I'll have to add that.

Sound right? Did I miss something? Thanks!
Aug 15, 2014 at 12:12 AM
Yes, it would indeed prevent this use case. This is a check inherited from the OIOSAML.NET project which explicitly doesn't use IDP initiated for their profile, apparently.

The check is valid if the response is not unsolicited (IDP initiated), which is the norm for most cases, and removing it in those cases would kind of defeat the purpose of that feature of the SAML 2 specification...

However, as it is a supported use case in the spec, we might need to just put in a configuration switch to "allowIDPInitiated" or something of the like on the identity provider elements in the config... there are already some other flags on those elements to disable other checks (e.g. signing checks, etc.).

Or in the short term, just comment it out and recompile. :-)

If you are so inclined to make a pull request, or a feature request with the contents of your message under "Issues", I can add something like that in the next release.
Aug 15, 2014 at 6:06 PM
I found myself wondering if this was even supported in the spec. I eventually found a good conversation about it here. That's when I realized the authors call it Unsolicited SSO intead of IdP-Initiated. That helped me find it in the spec (see section 4.1.5 or search for "unsolicited").
An identity provider MAY initiate this profile by delivering an unsolicited <Response> message to a service provider. An unsolicited <Response> MUST NOT contain an InResponseTo attribute, nor should any bearer <SubjectConfirmationData> elements contain one.
So ya, I'll open an issue, and I'll even attempt a pull request if I think my code changes are clean enough. Thanks!
Aug 15, 2014 at 6:49 PM
Yeah, that's what I was looking at too. As I said, the check is valid, so a configuration flag on the IDP element or similar may be the best option here to allow for unsolicited Responses. In SAML 1.1 IDP initiated was more the norm, with SAML 2, SP initiated is more the norm, and this check is in the spec because of that change (The old way could have been vulnerable to replay attacks, etc.).

I'd love to make this automatic, but from what I could see there's no way to identify a response as being IDP initiated automatically... which probably makes sense from a security standpoint. If I can specify how my attack should be validated, it gives me a foothold to really be manipulative. Making it a SP configuration value would allow me to specify that for a given IDP, I am OK with receiving unsolicited responses.

That's probably the route I will (or you can) take on this. As I said, the IDP configuration element already has several flags on it already for these types of things, so I'll probably just add an "allowUnsolicitedResponses" flag there.
Marked as answer by twamley on 8/15/2014 at 10:50 AM
Aug 16, 2014 at 5:52 PM
Rolled out in 2.4.5. I added a configuration value on the <identityProvider> configuration element called "allowUnsolicitedResponses" which you'd need to set to "true" in order to allow this.
Marked as answer by twamley on 8/16/2014 at 1:49 PM
Aug 16, 2014 at 9:54 PM
Well that was fast :) I tested in my environment and verified with SAML Tracer--it worked perfectly. Thank you, sir! Have a great weekend.
Aug 17, 2014 at 5:09 PM
LOL, well, you're probably the only one saying THAT right now... Your request was just the tipping point for me releasing a bug patch release finally. Some of the bigger feature pushes I'd like to do are going to require a full IDP that I can mess with for testing. I'd hate to put a new version out that suddenly broke everyone's SSO solutions, so I'm being cautious.