/SAML2/POST/SSO?SAMLRequest=...?

[Tom Scavo]

On Tue, Sep 1, 2015 at 4:15 PM, Tom Poage <tfpoage at ucdavis.edu> wrote:
> A vendor is trying to convince me that sending an AuthnRequest with a
> GET on the /SAML2/POST/SSO URL with the SAMLRequest as a query argument
> is valid because it works with 'several' (non-Shibboleth) implementations.

The IdP tells the SP what the protocol endpoint at the IdP is. (The
nerve of some people :)

> Our 2.x IdP rejects it. As expected, SSO works when they change the SSO
> profile to Redirect (FWIW we happen to be their first Shibboleth
> integration).

Sounds like you're in for a bit of fun :-D

> Although I see examples of POST (w/ XHTML form) vs. Redirect for SSO,
> plus e.g. the SAML2int profile mentions HTTP-REDIRECT is a MUST, I'm
> having difficulty finding that adding SAMLRequest on a GET to the
> /SAML2/POST/SSO actually violates the Oasis specs. E.g.
> saml-bindings-2.0-os.pdf sec. 3.5 which uses "may":

The spec doesn't specify the protocol endpoint of any SAML entity.
That's up to the entities to negotiate themselves. SAML metadata is
useful for that purpose ;-)

>> The HTTP POST binding defines a mechanism by which SAML protocol messages
>> may be transmitted within the base64-encoded content of an HTML form control.
>
> Perhaps I'm looking in the wrong place? Or--though perhaps
> ill-advised--nothing prohibits it other than the Shibboleth IdP
> implementation?

I'm not sure what else to say.

> P.S. just noticed the Wikipedia article on SAML 2.0 says /SAML2/SSO/POST
> and /SAML2/SSO/Redirect (vs. /SAML2/POST/SSO and /SAML2/Redirect/SSO).

Ha, I wrote that article!

> I guess as long as metadata is consistent.

That's all that matters, yes.

Tom