...
Session initiators (SessionInitiators) are service provider handler (ServiceProviderHandler) functions configured using the (duh) /Applications/Sessions/SessionInitiator element, of which there can be any number. Each can be assigned a name using the id attribute, and the default initiator can be identified with the isDefault attribute. They serve two purposes in the running SP:
...
Previous versions of Shibboleth had inline code within the filter that redirected the browser to the Application/Sessions/@wayfURL location using the Shibboleth authentication request profile (AuthnRequest; the shire/target/providerId stuff). As of Shibboleth 1.3, this has been generalized for the future, but currently has the same behavior. The default SessionInitiator element's wayfURL attribute provides the location of the IdPDiscovery service to use and the wayfBinding attribute contains a URI that identifies the binding/profile to use for the AuthnRequest . Currently, only the Shibboleth profile is supported, with the value urn:mace:shibboleth:1.0:profiles:AuthnRequest . Future plugins and versions will support additional wayfBinding values.
An additional new feature of Shibboleth 1.3 is the RequestMap's new requireSessionWith attribute, and comparable ShibRequireSessionWith Apache command. The only difference is that instead of a true/false value, the value of this setting should match the id attribute of a SessionInitiator element in the corresponding application. This effectively allows for multiple WAYF services to be utilized based on which resource is being accessed.
...
For a specific definition of what a lazy Session (LazySession) is, refer to that topic. This section addresses the way to establish a session lazily using the session initiator "protocol" supported by Shibboleth 1.3. The presence of a SessionInitiator/@Binding attribute containing the URI value urn:mace:shibboleth:sp:1.3:SessionInit indicates support for this custom protocol within the Shibboleth SP. While it can be invoked by any entity on the network, since it amounts to a browser redirect, it is not intended as a standard, interoperable mechanism between federated systems, and not all Shibboleth implementations can be assumed to support it. Think of it as an internal (but documented and stable) API.
A SessionInitiator is a ServiceProviderHandler, which means that it exposes SP-specific functionality at a virtual resource location living within the web server's resource tree. As with other handlers, the SessionInitiator/@Location attribute is appended to the Sessions/@handlerURL value to compute the path at which the endpoint lives. To make use of the session initiator, the browser must send an HTTP GET request to that location with an optional set of query string parameters:
...
$ providerId: The name of an IdP to request a session from. This bypasses the IdPDiscovery process (if for example an application has already carried out that step itself, or if the application has cached the source of an earlier session and simply wants to renew it). If not specified, the SessionInitiator/@wayfURL attribute determines the location to which the AuthnRequest is sent.
...
Of special mention is that when a providerId parameter is sent with the GET request to a SessionInitiator, SAML MetaData is used to determine how and where to send the resulting AuthnRequest message. The exact options in this step depend on the capabilities present in the Shibboleth version used. In Shibboeth 1.3, unmodified, only entities that support SAML 1.x and the Shibboleth AuthnRequest profile can be "located".
...