AssertionConsumerService configuration

[nawatts]

The SP needs to be configured to be aware of the host@fqdn ACS made available by mech_saml_ec. However, the Location property of ACS configuration in shibboleth2.xml is relative.

This configuration is necessary for:

• To know which binding (#13) to use. Which bindings are available will depend on SP and IdP configuration.
• For cases like Palmetto, where the ACS location will be different from the machine's hostname.

The ACS docs mention that Location is relative to base handler URL, so maybe if there's a way to set the base handler to an empty string, a host@fqdn ACS could be configured. But that would probably interfere with the default configuration of other ACSs.

[spaetow]

Is there a way to 'normalise' it to host/fqdn or just fqdn (given that you'll most likely get host as the service by default)?

[nawatts]

I believe the host@fqdn format comes from GSS. From Kerberos documentation:

A GSSAPI application can name a local or remote entity by calling gss_import_name, specifying a name type and a value. The following name types are supported by the krb5 mechanism:

• GSS_C_NT_HOSTBASED_SERVICE: The value should be a string of the form service or service@hostname

It looks like this will not be possible though, as the SP assumes all handler endpoint URLs will be HTTP(S). https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions#NativeSPSessions-HandlersandEndpointConstruction

[spaetow]

Yes, but you do other things in your mechanism (like picking apart the user@identity-provider string before you pass that on to the IdP), correct? Is something similar possible for the SP end of looking up whether an ACS exists for the FQDN? Sorry, displaying my cluelessness of the mechanism's inner workings.

[nawatts]

Yes, it is. As it turns out, the SP C library returns ACS Locations as the relative paths in the configuration, not the fully constructed URL. So no parsing necessary in the mechanism. So the SP's generated metadata would have to be edited before passing it to the IdP (assuming a host@fqdn location in the configuration doesn't cause an error when starting the SP). But it's recommended that the generated metadata not be piped straight to the IdP anyway.

However, the mechanism extracts the ACS Location from the SP configuration, builds up a URL from it, and then ignores it all and uses the GSS name that's passed in to the getSAMLRequest2 function (SAML2XML.cpp L278). That looks to be created from the result of gethostname (util_cred.c L484).

So to satisfy the case where the ACS Location with an FQDN will be different from what's seen by gethostname (ie Palmetto where gethostname returns user001 but we need the user.palmetto.clemson.edu), maybe we could prefer:

1. Location of ACS with Location host@* and Binding urn:ietf:params:xml:ns:samlec (#13) (based on shibboleth2.xml).
2. Location of ACS with Location host@* and Binding urn:oasis:names:tc:SAML:2.0:bindings:PAOS (based on shibboleth2.xml).
3. GSS service name (based on gethostname).
4. Location of ACS with any Location and Binding urn:oasis:names:tc:SAML:2.0:bindings:PAOS (based on shibboleth2.xml). I don't see how this would work, but this is what the mechanism currently uses if no GSS service name is passed in.

As for the Binding of the request, the SP doesn't support urn:ietf:params:xml:ns:samlec for ECP requests (yet), so the request would have to be sent with urn:oasis:names:tc:SAML:2.0:bindings:PAOS. To prepare for the future, we could have the mechanism use samlec if it finds an ACS with that Binding in the SP configuration. And I think we would want to continue supporting the ability to use PAOS in the future anyway, to maintain compatibility with the current version of the SP.

[nawatts]

I keep going in circles (see comments on #13)... This doesn't belong in shibboleth2.xml. Adding <md:AssertionConsumerService Location="host@<fqdn>" Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" /> to shibboleth2.xml configures a PAOS handler at <fqdn>/Shibboleth.sso/host@<fqdn>, which is clearly not desired. Adding an ACS with the urn:ietf:params:xml:ns:samlec Binding causes an exception when starting shibd.