The <Sessions> element broadly speaking controls how the SSO process is managed by the SP. It typically contains a number of child elements called "handlers" that act together to provide the core SAML functionality of the software. It also contains settings that govern how long SSO sessions last and how they're protected from certain kinds of attacks.
Each <ApplicationOverride> inherits the default settings and endpoints defined at the top level, and can contain its own <Sessions> element, if needed, to add additional endpoints. Note that if you supply a <Sessions> element in an override, virtually none of its individual XML attribute properties will be inherited from the default element. You must supply almost all of them that you want to have non-defaulted values. In contrast, the elements from the parent <Sessions> element do get inherited/used if you don't override them. It's not terribly intuitive, an artifact of the code. See Inheritance Rules for more details.
...
Virtually all configurations should stick to the simplified syntax for auto-configuring protocol-related handlers in terms of "services" and "protocols". The currently supported services are:
A service is enabled by including the corresponding child element(s). Each service element contains a set of properties to configure the service, and the element's value is a list of protocol names that the SP supports. Each supported service element can appear only once, as this is a simplified approach that is meant to capture all of that function's behavior in a single element. More advanced cases may require reverting to older syntaxes, but this isn't usually necessary and you may want to ask on the support list before reverting to that.
| Info |
|---|
These services and names are used to locate detailed information about the handlers to install based on a You can still plugin all of the older information by hand if you need unusual settings or more control over the internals but that will create a much higher burden on future maintainers of your configuration so should usually be avoided. If you absolutely have to do it, it's best to replace the new elements entirely to avoid unforeseen overlaps and interactions. |
...
The usual content of the <Sessions> element will be one or more "service" elements, along with an optional set of custom <Handler> elements for more general features.
...
The usual content of the <Sessions> element will be one or more "service" elements, along with an optional set of custom <Handler> elements.
Name | Cardinality | Description |
|---|---|---|
0 or more | Initiates sessions by creating an a request for authentication specific to a particular SSO protocol, or invoking some kind of IdP discovery mechanism. | |
0 or more | Terminates a session by invoking some kind of logout process, which may be local to the SP or global to the SSO environment. | |
0 or more | Incoming entry point for messages carrying SAML SSO assertions to initiate a user session. The terminology is borrowed from the SAML spec (as is the actual element). | |
0 or more | Incoming SOAP endpoint for the resolution of SAML 2.0 artifacts into protocol messages. This is used when transmitting outbound messages as artifacts by the SP, which is borderline unheard of. (Artifacts issued by an IdP are processed by other endpoints.) The terminology is borrowed from the SAML spec (as is the actual element). | |
0 or more | Incoming entry point for single logout protocol messages from an IdP (acting in its role as a session authority). The terminology is borrowed from the SAML spec (as is the actual element). | |
0 or more | Incoming entry point for NameID management messages from an IdP. The terminology is borrowed from the SAML spec (as is the actual element). |
...