Versions Compared

Old Version 9

changes.mady.by.user Rod Widdowson

Saved on

compared with

New Version Current

changes.mady.by.user Rod Widdowson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

As described above, the protocol for this feature is proprietary and is defined by the Shibboleth software. The interface to ask the IdP to respond to an SP without the SP having made a request involves the use of some defined query string parameters.

Localtabgroup
tabStyleflat
Localtab live
activetrue
Expand
titleSAML 1.x

In older 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.

Out of the box, requests are handled at https://hostname/idp/profile/Shibboleth/SSO (replacing hostname with the location of your IdP) and the following query string parameters can be used:

  • providerId

    • the name (i.e., the entityID) of the service provider

  • target

    • a 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.

localtab-live
Expand
titleSAML 2.0

The original SAML 1.x protocol 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 location in the IdP; that is, you can't send the request to one location and have the IdP figure out which SAML version to use. It's simply an alternative request format that requires the identified SP support SAML 2.0.

Out of the box, this endpoint can be found at https://hostname/idp/profile/SAML2/Unsolicited/SSO (replacing hostname with the location of your IdP) and the following parameters can be used:

  • providerId

    • the name (i.e., the entityID) of the service provider

  • shire (optional)

    • URL of the SAML 2.0 response location at the SP (the "Assertion Consumer Service"), but can be omitted in favor of the IdP picking the default ACS location from the SP's metadata

  • target (optional)

    • corresponds to RelayState in the SAML 2.0 protocol, but can generally be omitted

  • time (optional)

    • a timestamp to help with stale request detection

As you can see, this is the same protocol as before, 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 (you don't want to know the origin of the name "shire", but it doesn't involve hobbits).

...