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). |