AuthnContext check in IdP response

[Scott Cantor]

> Is this a good practice for a SP requiring a specific authContext to also explicitely check IdP response ?

It's absolutely essential practice unless you intend to operate with unsolicited responses disabled. The SP doesn't default to that because of the SAML standard's requirements for that, and it didn't even support it until pretty recently (relatively speaking).

The history was that you had to do it so it's somewhat historical but also based on the fact that it takes a lot of additional steps and overhead to avoid doing it, and that doesn't make a whole lot of sense most of the time.

And that assumes one actually trusts the correlation layer so that one could issue signed requests and trust that responses back were associated with them. And the SP doesn't track the details of the requests. V4 does, and eventually we were going to look at what controls to attach to that in the Hub given that it's possible to do that now.

With V3, you have to just assume that you always make the request the same way to a given IdP and that if the response is correlated, you could maybe assume, but it's just not really set up to do that.


> It seems simpler to consider than if you don't trust this IdP behavior, you may as well not trust it at all, and disallow any kind of interaction with it.

Most of the world doesn't use federation, and indeed in those cases, they do tend to just live with "assume IdP does X out of band". The recent Salesforce stuff is probably among the only widespread commercial case of anybody out there trying to use this stuff outside of our world where we understood that IdP assumptions don't scale.

> And if it's a defense in depth issue, why isn't this check automatically get enforced by Shibboleth SP itself ?

Because it didn't retain knowledge of what it requested, since most requests were always left unsigned. Signing requests and disallowing unsolicited responses are both a precondition to a model in which you then also track the information to enforce it.

> Given it may be non-trivial checking the result of requests using comparaison operators, such as "https://refeds.org/profile/sfa or better", this would probably better handled in SAML implementation than delegated to the web server, or the client application.

That's true, but the SP could never have done that (until V4) and of course nothing but Shibboleth ever supported, or ever will support, anything but exact, so....

-- Scott