Validation of InResponseTo field in a Java-based SP

[Cantor, Scott]

> I am reviewing a piece of code in a java application that attempts to utilize
> open-saml v3 functionality as an SP.  The code seems to execute validation
> processes on the response received and one of the checks that it does is, it
> makes sure the response.getInResponseTo() is not null or an exception is
> thrown. While this check appears to work in SP initiated authN, it proves
> impractical for IdP initiated authN as the call always returns null.

Obviously. IdP-initiated SSO is itself a security flaw in SAML, but that aside...

> My questions are: is the check really necessary and does it provide value?

Checking for a non-null value is pointless. The only point to checking it is to cross check it against the ID of a request issued by the SP, plugging the XSRF attack vector that IdP-initiated SSO inherently exploits. It requires a stateful SP that remembers its requests. The Shibboleth SP for example does no checking because it doesn't remember its requests, so has nothing to check against.

> and assuming that it is, what might be a proper strategy to make sure the
> code can work in both SP and IDP initiated authN modes?

If you support IdP-initiated, you have to accept essentially any response with a null correlation because that's what it means to support that. If you get a non-null correlation, then you have to either check it against a state token, or ignore it. So there's nothing complicated about supporting both, it's cross-checking at all that's a bit of work.

My opinion is that cross-checking is pointless unless you implement an option to block IdP-initiated, because it's not going to buy you anything.

-- Scott