<SSO> element is used to enable and configure support for Single Sign-On/Authentication protocols within the SP. This is of course the primary function of the software, so it is generally present within the
<Sessions> element to enable and control SSO settings. It replaces the functions of the
<md:AssertionConsumerService> handler elements from the older (pre-2.4) configuration.
Instead of defining explicit endpoints with low-level binding information, the <SSO> element automates the installation of the appropriate handlers based on the protocols selected for activation. For each protocol activated in the <SSO> element, the order of the Bindings is controlled in
protocols.xml. Most of the remaining settings are equivalent to the settings supported by the "common" <SessionInitiator> types. Note that the <SSO> element supports many of the attributes of <SessionInitiator>, so some of the default settings can be modified without having to define an entire <SessionInitiator>.
The use of the
<SSO> element results in a basic chain of initiator plugins installed at the recommended
"/Login" handler location. For advanced scenarios that require additional plugins or options, additional explicit
<SessionInitiator> elements can be added to the end of the surrounding
<Sessions> element. To prevent unforeseen interactions, you may want to remove the shorthand element entirely.
A basic example using a single, fixed IdP, supporting the usual common SAML protocols:
<SSO entityID="https://idp.example.org/idp/shibboleth"> SAML2 SAML1 </SSO>
An example using a SAML Discovery Service and supporting ECP:
<SSO discoveryProtocol="SAMLDS" ECP="true" discoveryURL="https://examplefederation.org/DS"> SAML2 SAML1 </SSO>
For a legacy Shibboleth WAYF Service, just replace the
discoveryProtocol value with
relayStatesetting from the
"providerId"are the parameter names supported. This is provided for supporting unusual application requirements.
Other attributes supported include settings specific to various types of
<SessionInitiator> plugins to alter the behavior of specific protocols. For example, as above, you can enable ECP support by adding the
ECP flag, supported by the
SAML2 initiator plugin.
The content of the element is a whitespace-delimited list of "protocol" identifiers. Protocol identifiers are listed in preferential order, with the most preferred first. The following are built-in to the SP:
An additional protocol is supported if the relevent extension is loaded:
Other protocols can be "integrated" with the service-based configuration mechanism by supplying the relevant information via the
<ProtocolProvider> plugin interface.