Page tree

Previous Stable Release

Please note that the V3 release branch is now the previous stable release, with the current stable releases from the V4 branch.
Support for V3 will end on Dec 31, 2020.

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 3 Next »

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

Format: Native Spring / Deprecated Custom Schema

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


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.


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 officially supported 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 for now, you would need to edit system/conf/webflow-config.xml and remove the flow/endpoint definition, and maintain that change across upgrades.

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
    • Name 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