Módosítások

* Implements SAML2 Single Logout profile (not the full specification, see the Missing features section below for details).* User If initiated by an SP, user must confirm the single logout process, : one can choose to logout only from the initiating SP and the IdP.

* initiating front-channel or back-channel logout to one SP (<code>SLOServlet?logoutaction&entityID=...</code>)

The controller renders a page where an iframe is placed for every active session participant. This iframe calls the <code>SLOServlet?logoutaction&entityID=...</code> URL where the logout request is issued for the given session participant. If the request is front-channel, the iframe will make a front-channel SAML message exchange with the peer (using HTTP-Redirect or POST bindings).

With javascript disabled==== IdP-initiated Logout (available since v2.1.3-slo2) ====The user can initiate their logout process from the IdP (the URL is <code>/idp/Logout</code>). IdP-initiated logout has a clear advantage over SP-initiated logout, because the timeout URL and the UI is not possible, so if one session participant fails to respondfully independent from the current SP software used, thereby providing a unique logout URL for all users of the user gets stuck on the status pagegiven IdP.

;You have two choices* instruct the SP to sign messages * configure the IdP not to require authentication of logout messages (and bear with possible DOS-attacks)==== Signing messages is quite common ===={|{{prettytable}}|Signing can be turned on by setting the '''<code>signing</code>''' property to '''<code>front</code>''' (for front-channel only) or '''<code>true</code>''' in the <code>ApplicationDefaults</code> or <code>ApplicationOverride</code> element in shibboleth2.xml.|}{{NOTE_EN|Signing messages but is normally unnecessary for back-channel, as the transport is usually authenticated with the certificates in the metadata. However, for back-channel logout it is the IdP who initiates the HTTP connection to the SP, and it is the '''webserver''', who answers the request. Because of the different needs, the webserver almost always uses a different certificate (a server certificate signed by a well-known server certificateCA) than the SP (possibly self-signed, client certificate). '''Therefore the SP must sign back-channel messages as well to authenticate itself to the IdP.'''{{INFO_EN|Signing Unfortunately, you can be turned on by setting the '''<code>only enable signing</code>''' property to '''<code>true</code>''' in the <code>ApplicationDefaults</code> or <code>ApplicationOverride</code> element in shibboleth2.xmlall (otherwise transport protected) messages, and this may affect performance.}}

This is required for back-channel logout to work==== Not requiring peer authentication ===={|{{prettytable}}|Message issuer authentication can be turned off by changing the security policy of processing Single Logout messages. Unfortunately, You can do this enables signing all (transport protected) messages as well, which might affect performanceby commenting out the following line from the block '''<code>SAML2SLOSecurityPolicy</code>''' at '''<code>relying-party. xml</code>''':::<source lang="xml"><security:Rule xsi:type="security:MandatoryMessageAuthentication" />}</source>|}

{| {{INFO_ENprettytable}}|This can be set in the <code>relying-party.xml</code> by specifying the number of milliseconds in the '''<code>maximumSPSessionLifetime</code>''' attribute of the '''<code>SAML2SSOProfile</code>''' configuration.}|}

== Required changes in the IdP API ==

* IdP-initiated logoutLogout the user in the underlying JAAS provider