Options for the SP-side of the SAML authenticator in IdPv4?

[Cantor, Scott]

On 8/5/20, 11:12 AM, "users on behalf of Jeremy A Scott" <users-bounces at shibboleth.net on behalf of jeremy.scott at wisc.edu> wrote:

>    One thing continues to be a mystery though, and that is how do we configure things that influence the SP side’s
> outbound AuthnRequest?

relying-party.xml and the SAML2.SSO profile bean (the relying party ID in this case is the proxied IdP rather than an SP). And of course that's all doable with metadata tags, but same thing. This is subtle but works very well and has been pretty sensible when you actually start doing it.

>    So the genesis of this question is that one of our Proxied IdP partners noticed a change in the AuthnRequest from the
> new v4 Proxy IdP that unfortunately caused an outage for them.   The attribute ‘ProtocolBinding’ is missing, and
> apparently their IdP needs this to function in order to select the proper ACS endpoint.

Oversight. I hadn't actually realized the implications of that on the IdP itself since the Shibboleth SP always includes it, it affects how endpoints are validated. Anyway, there's no option to control that but I would just want to do it by default, so file a bug.

>    Is there a way we can do this and make the new outbound AuthnRequest behave the same as it did before by
> including the ProtocolBinding attribute? 

No, since "before" wasn't this code at all, they're just different SAML SPs.

>    Or, is there some other solid argument we can make for not doing this and replying to that IdP operator that their
> software is not following the standard?

Well, it's definitely not following the standard, if that's the argument you want to go with.

But I believe in being unambiguous so I think the IdP should send it and would prefer it just did that.

We only support HTTP-POST right now, there didn't seem much value in bothering with anything else. ECP "maybe", but replaying authentication is a) not always possible and b) subject to lots of attacks and concerns, so that's why I skipped it.

-- Scott