The Shibboleth IdP V3 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP4 wiki space for current documentation on the supported version.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Current »

File(s): conf/relying-party.xml

Format: Native Spring / Deprecated Custom Schema

Legacy V2 File(s): conf/relying-party.xml

Overview

Usually in Shibboleth, the flow is assumed to be an SP requesting authentication by redirecting the client to the IdP, and then getting back a response. In the original SAML 1.0 and SAML 1.1 standards, though, SSO was described in only semi-interoperable terms as a response from the IdP to the SP, and the "request" portion was left out. This was carried over into SAML 2.0 as a mode called "IdP-initiated" or "unsolicited" SSO.

While this approach lacks interoperability, it has perceived benefits for some service providers; they get to do less work and push that work onto users and IdPs. So it isn't unusual to find SPs that refuse to support the standard fully and insist on this approach.

What is misunderstood about this feature is that it is not interoperable, despite being part of the standard. Interoperability requires a well-defined message, and the basic idea behind IdP-initiated SSO is that the message is up to the IdP. Something has to initiate the process, it can't magically start for no reason. So there is a request to the IdP, but it isn't a SAML message and no two IdPs are likely to work the same way. It's a proprietary mechanism.

Configuration

There is no special configuration for this use case, it's subsumed into supporting Browser SSO for SAML 1 and SAML 2 for a relying party. In the default configuration, both are enabled using the profile configuration beans named "Shibboleth.SSO" and "SAML2.SSO".

There is currently no simple method of disabling the Unsolicited SSO support for SAML 2 separately from the overall support for SAML 2 SSO. If you need to disable this feature, it's possible in V3.3 and above to remap existing profile locations to your own flow definitions; you can inquire on the support list if you want to do this.

Another way you can disable support for this feature for specific services is by modifying their SAML metadata to include AuthnRequestSigned="true" in the <SPSSODescriptor> element. Doing so causes the IdP to require requests from that SP to be signed, and since this protocol does not allow for signing, it will cause such requests to fail with an error.

Request Interface

SAML 1.x

In the original Shibboleth versions, the lack of a request message in SAML 1.x was supplemented with a simple request format defined in the Shibboleth Protocol Specification. Simply defined, it's a redirect with a small set of parameters:

  • providerId
    • the name (i.e., the entity ID) of the service provider.
  • shire
    • the URL of the response location at the SP (called the "Assertion Consumer Service")
  • target
    • the target resource at the SP, or a state token generated by an SP to represent the resource.
  • time (optional)
    • A timestamp to help with stale request detection.

Formally speaking, this is not IdP-initiated SSO; it's a proprietary request to the IdP that results in a response to the SP. If you refer back to the initial discussion above, you can see that that's actually the definition of IdP-initiated SSO.

SAML 2.0

The original protocol extension was adapted so that it can be used to trigger SAML 2.0 SSO in addition to legacy SAML 1.x responses. The two protocols are not supported at the same endpoint; that is, you can't send the request to one endpoint and have the IdP figure out which protocol to use. It's simply an alternative request format that requires the identified SP to support SAML 2.0.

Out of the box, this endpoint can be found at /idp/profile/SAML2/Unsolicited/SSO and the following parameters can be used:

  • providerId
    • the entityID of the service provider.
  • shire (optional)
    • URL of the response location at the SP (the "Assertion Consumer Service"), but can be omitted in favor of the IdP picking the default endpoint location from metadata.
  • target (optional)
    • Corresponds to RelayState in the SAML 2.0 protocol, but can be omitted.
  • time (optional)
    • A timestamp to help with stale request detection.

As you can see, this is the same protocol as in the old days, but with more optional parameters, reflecting how we would have designed the protocol if we were starting from scratch today. Protocol syntax is compatible with the original so that existing links can be easily adapted and used, despite the fact that the terminology is outdated.

  • No labels