...
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, SAML 2.0 is enabled using the profile configuration bean named "SAML2.SSO", the same one that configures the behavior of the normal request/response usage of the profile.
Note that while SAML metadata for the SP is required, as it always is, there's nothing in particular about this use case that's evident from the metadata you have to provide (or, often, build yourself; the Venn diagram of "requires IdP-initiated SSO" and "doesn't supply metadata" is round). The SP's metadata is in general the same as it would be in any other scenario.
One caveat: metadata containing the AuthnRequestsSigned flag set to true will disallow this flow since the unsolicited message to the IdP is not signed.
Disabling
There is currently no simple method of disabling the Unsolicited SSO support for SAML 2 separately from the overall support for SAML 2 SSO. Blocking the URL outright via a web server rule is the most obvious way to do it.
...
| Expand | ||
|---|---|---|
| ||
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:
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. |
| Expand | ||
|---|---|---|
| ||
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:
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). |
...
The examples assume the default locations supported out of the box, which should rarely need to be adjusted, and an IdP located at idp.example.org.
They also assume proper metadata is loaded into the IdP. There is nothing special about the metadata required to use this feature, it's the same metadata required for any use of the corresponding SP, and if you have to create that by hand because you're working with a deficient partner and/or outside the context of a federation, see other topics and examples to explore how to do that.
...