NativeSPSingleLogoutService
The <md:SingleLogoutService>
element is used to configure handlers that are responsible for processing logout protocol messages from an IdP. These are protocol specific, but generally fall into two classes: requests, which tell the SP to perform a logout, and responses, which conclude a logout event initiated by the SP.
As a multi-protocol system, the SP itself is oblivious to specific logout protocols; each handler provides the implementation of a particular logout protocol.
Common Attributes
Location
(relative path)- The location of the handler (when combined with the base handlerURL). This is the location to which an IdP sends messages using whatever protocol and binding it shares with the SP. Each combination of SLO protocol and binding is installed at a unique location to improve efficiency.
Binding
(URI)- Identifies the protocol binding supported by the handler. Bindings describe how the message is packaged by the IdP (or by the browser in some cases) for consumption by the handler.
signing
(see NativeSPSigningEncryption) (Version 2.6 and Above)- Controls outbound signing of XML messages subject to applicability to the protocol involved.
encryptionÂ
(see NativeSPSigningEncryption) (Version 2.6 and Above)- Controls outbound encryption of XML messages and content subject to applicability to the protocol involved.
SAML 2.0 SingleLogoutService
The SAML 2.0 logout handler implements the SAML 2.0 Browser Single Logout profile. The incoming message may be a <samlp:LogoutRequest>
or <samlp:LogoutResponse>
.
If the message is a request via a front-channel binding, then the following steps are performed. If an error occurs at any point, an effort is made to respond to the requesting IdP with a <samlp:LogoutResponse>
containing the error.
- Verification of the information in the request against the active session is done.
- Any of this user's sessions being logged out other than the active session are removed from the cache.
- Front and back-channel application notification loops are executed.
- A
<samlp:LogoutResponse>
is returned to the requesting IdP. The status indicates whether the SP believes that the logout completely succeeded.
If the message is a request via a back-channel binding, then the following steps are performed:
- The request content is used to obtain a list of applicable sessions to remove.
- The sessions are removed.
- The back-channel application notification loop is executed.
- A
<samlp:LogoutResponse>
is returned to the requesting IdP. The status indicates whether the SP believes that the logout completely succeeded.
If the message is a response, then the SP completes the logout operation by redirecting to the browser to a location preserved by relay state, if any, or the globalLogout
template is displayed.
The following Binding
values are supported:
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact
urn:oasis:names:tc:SAML:2.0:bindings:SOAP
ADFS SingleLogoutService
The ADFS handler is only available if the adfs.so
extension library is loaded by the SP.
Generally this handler need not be configured directly, because ADFS requires that it be co-located with the endpoint responsible for incoming assertions.
The ADFS handler implements the Microsoft ADFS signout protocol. The following steps are performed:
- Front and back-channel application notification loops are executed.
- The active session is removed from the cache.
- If a "wreply" parameter is provided, the browser is redirected to it.
- Otherwise, the
globalLogout
template is displayed.
The following Binding
values are supported:
http://schemas.xmlsoap.org/ws/2003/07/secext