In the past, Service Providers with multiple hostnames or wildcard aliases have needed to add an endpoint URL in their metadata (the AssertionConsumerService elements) for every hostname so that the IdP could verify that the endpoints in authentication requests were valid. Stanford’s IdP now supports skipping that verification if the authentication request is signed by the same keypair already used by a Service Provider.
In other words, if your Service Provider signs its authentication requests, you don't have to add any AssertionConsumerService elements to the metadata you submit to the SPDB thereby making updates and maintenance of that metadata simpler. For this reason we recommend you configure your Service Provider to sign authentication requests; see the section "Service Providers: Enable signing for authentication request" below for details on how to do this.
How it works
When the IdP receives a login request from an SP, the request contains the SP's entity ID and a handler URL endpoint, where it wants the authentication SAML message to be delivered.
With the “skipEndpointValidationWhenSigned” configuration, the process for checking the handler URL is more efficient.
- Login request SAML message signed by the SP key: The IdP will accept the handler URL as passed, without checking it against the metadata endpoint list.
- Login request SAML message not signed (the original IdP configuration): The handler URL must match an existing endpoint in the metadata. If the handler URL doesn't exactly match the list, the login request will be refused, and the SP will need to update the endpoint list in the metadata.
What it solves: virtual hosts and wildcard hosting systems
Bypassing endpoint checks in metadata with the new IdP configuration solves for two considerably cumbersome use cases.
- Multiple virtual hosts. When SPs are used to protect sites with multiple virtual hosts, each virtual host must use its own domain name in its handler URLs. Each domain name must also be enumerated in the metadata so that the login request will pass through the IdP. Every time a new virtual host is added, the metadata will need to be updated and the metadata files will continue to grow longer.
- Wildcard hosting systems. When the domain is a wildcard hosting system, or *.domain.stanford.edu, and is registered to the server IP, the original IdP configuration will not work. Though subdomain hosts can be added to the system at any time, you cannot put *.domain.stanford.edu into endpoint URLs. As a result, the IdP will refuse all login requests.
Service Providers: Enable signing for authentication request
To simplify Service Provider (SP) configurations, especially those that use multiple endpoints, your Service Providers should enable authentication request signing.
How to enable signing for authentication requests:
- For Apache mod-shib, here is part of a sample shibboleth2.xml file enabling authentication request signing:
<ApplicationDefaults entityID="https://your-entity.stanford.edu/sp/shibboleth" signing="true" REMOTE_USER="eppn uid">
- For SimpleSAMLphp applications:
sign.authnrequest=true
