Use urn:ietf:params:xml:ns:samlec AssertionConsumerService Binding

[nawatts]

https://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-13 specifies:

If metadata is used, a SASL service's role MUST contain a corresponding whose Location attribute contains the appropriate service name, as described above. The Binding attribute MUST be one of "urn:ietf:params:xml:ns:samlec" (RECOMMENDED) or "urn:oasis:names:tc:SAML:2.0:bindings:PAOS" (for compatibility with older implementations of the ECP profile in existing identity provider software).

However, mech_saml_ec is coded to only look for an ACS with a PAOS binding.

• verifySAMLResponse (SAML2XML.cpp#L614) requires only that any PAOS ACS be present.
• getSAMLRequest2 (SAML2XML.cpp#L164) loads the Location configured by the first PAOS ACS in SP configuration, but then ignores it in favor of the GSS name (SAML2XML.cpp#L277).

Part of #13

[nawatts]

getSAMLRequest2 retrieves the first PAOS ACS from SP configuration. But then it uses the GSS service name for the request's ACS URL. It uses the PAOS ACS's Binding for the request's protocol binding. (SAML2XML.cpp#L290). But the request protocol binding was removed in draft 13 of the specification. (search for "ProtocolBinding" in the draft 12-13 diff). Does getSAMLRequest2 even need to look at the SP's ACS configuration?

verifySAMLResponse requires only that any PAOS ACS be present (SAML2XML.cpp#L639). But the ACS provided by mech_saml_ec isn't part of the SP configuration. So is this meant to verify that the SP supports ECP?

[nawatts]

The specification (draft 14 section 4.7) says:

For compatibility with existing IdP and profile behavior, and to provide for mutual authentication, the SASL server MUST populate the responseConsumerURL and AssertionConsumerServiceURL attributes with its service name. As discussed in Section 5.6.2, most SASL profiles rely on a service name format of "service@host", but regardless of the form, the service name is used directly rather than transformed into an absolute URI if it is not already one, and MUST be percent- encoded per [RFC3986].

The IdP MUST securely associate the service name with the SAML entityID claimed by the SASL server, such as through the use of SAML metadata [OASIS.saml-metadata-2.0-os]. If metadata is used, a SASL service's role MUST contain a corresponding

whose Location attribute contains the appropriate service name, as described above. The Binding attribute MUST be one of "urn:ietf:params:xml:ns:samlec" (RECOMMENDED) or "urn:oasis:names:tc:SAML:2.0:bindings:PAOS" (for compatibility with older implementations of the ECP profile in existing identity provider software).

So the only place the new binding should appear is on the ACS in the SP metadata provided to the IdP. However, the IdP has to support the binding (see comment on #13). If it does, then it remains to be seen if the SP will initiation the session (#25).

Request ACS URL is set in SAML2XML.cpp#L283 and Response Consumer URL in SAML2XML.cpp#L367.