...
Simplified Protocol Configuration
Mostly you just need Virtually all configurations should stick to the simplified syntax for auto-configuring protocol-related handlers by expressing support in terms of "services" and "protocols". The currently supported services are:
...
| 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 . Itbut 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.
Name | Cardinality | Description |
|---|---|---|
<SSO> | 0 or more | Enables support for one or more Single Sign-On / Authentication protocols |
<Logout> | 0 or more | Enables support for one or more Logout protocols. |
<NameIDMgmt> | 0 or more | Enables support for one or more NameID Management protocols. Rarely used. |
<Handler> | 0 or more | Generic endpoint for non-specific functionality implemented by the SP or an extension library. |
...
The above three elements are shorthand configuration for a more complex mechanism as described below using handlers explicit handlers.
Handlers and Endpoint Construction
...
Often, each application spans a particular virtual host, and the base location is simply "/Shibboleth.sso" on that vhost. In more advanced cases, an application might live inside a subset of a virtual host's document tree. In that case, the base location has to be inside that document tree (e.g., "/path/Shibboleth.sso"). Each handler element This is strongly discouraged, as it is very hard to configure.
Each handler element has a Location XML attribute that, when appended to the base location, provides the full path to the handler. Combining that path with the virtual host's scheme, hostname, and port, you have the full URL of the handler:
...
In turn, these endpoint locations are usually supplied to partner sites in Metadata. When they don't match the metadata, various errors will result.
Advanced Configuration by
...
Protocol
The advanced child elements listed below have variants for each protocol type and are documented as such. However deployers are liable to care about a particular protocol. Session configuration for each protocol in the following subsections
...
There is also support for Local-only logout.
Child Elements
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 |
|---|---|---|
| <SessionInitiator> | 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.Generally Almost always superseded by the element; you should not in general ever need to consider configuring this directly. |
| <LogoutInitiator> | 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.Generally Almost always superseded by the |
| <md:AssertionConsumerService> | 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). Almost always superseded by the |
| <md:ArtifactResolutionService> | 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 not commonborderline 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). Almost always superseded by the various service elements; you should not in general ever need to consider configuring this directly. |
| <md:SingleLogoutService> | 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). Almost always superseded by the <Logout> service element
|
| <md:ManageNameIDService> | 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). Almost always superseded by the <NameIDMgmt>service element
|