This page shows how to safely migrate a production IdP deployment to SAML V2.0 Web Browser SSO. We assume the IdP deployment is currently issuing SAML V1.1 assertions and has the ability to issue SAML V2.0 assertions. If the IdP software supports IdP-initiated SAML Web Browser SSO, the migration can occur gradually without abruptly opening the doors to arbitrary SAML V2.0 SPs.
A flow involving an unsolicited SAML response is called IdP-initiated SAML Web Browser SSO. In the SAML V1.1 standard, this is the only supported mode of operation. With the introduction of SAML V2.0, SP-initiated flows became commonplace, and in fact IdP-initiated flows were all but forgotten. Here we leverage this quiescent capability to facilitate IdP migration to SAML V2.0.
Preconditions:
- The IdP software supports both SAML V1.1 and SAML V2.0
- The IdP deployment is currently in production
- The IdP deployment is currently issuing SAML V1.1 assertions
- The IdP software supports IdP-initiated SAML V2.0 Web Browser SSO
Procedure:
- Add an
<md:ArtifactResolutionService>endpoint to IdP metadata - Configure a SAML V2.0 endpoint in the IdP software
- Trigger an unsolicited response from the previously configured SAML V2.0 endpoint
Procedural details:
At step 1, a superfluous <md:ArtifactResolutionService> endpoint that supports the SAML V2.0 SOAP binding is added to IdP metadata to work around a limitation of the metadata administrative interface. The appearance of this endpoint triggers the web application to add SAML V2.0 protocol support in metadata, which is enough to let the IdP push a SAML V2.0 response to an SP. Since there is no <md:SingleSignOnService> endpoint with a SAML V2.0 binding in metadata, an SP can not issue a SAML V2.0 authentication request to the IdP.
The IdP software is configured for SAML V2.0 at step 2. (It's possible that your software was configured for SAML V2.0 out of the box, but since your IdP metadata does not include an <md:SingleSignOnService> endpoint with a SAML V2.0 binding in metadata, there is no way for an SP to issue a SAML V2.0 authentication request to your IdP.) We will use this SAML V2.0 endpoint to issue an unsolicited SAML V2.0 response to an arbitrary SAML V2.0 SP at the next step.
Since the method to trigger an unsolicited SAML V2.0 response is software-specific, step 3 depends on your particular software implementation. If you are using the Shibboleth IdP software, a mechanism to elicit an unsolicited SAML V2.0 response is documented in the Shibboleth wiki. The simpleSAMLphp IdP also supports IdP-initiated login and therefore IdP-first flows. For other implementations, consult your documentation.