„Single Logout in Shibboleth IdP” változatai közötti eltérés

Innen: KIFÜ Wiki
a (v2.1.4-slo3)
(Released versions)
105. sor: 105. sor:
 
* download the latest binary snapshot version from our [https://www.aai.niif.hu/software software distribution site]
 
* download the latest binary snapshot version from our [https://www.aai.niif.hu/software software distribution site]
  
==== v2.1.4-slo3 ====
+
==== v2.1.4-slo4 ====
 
* updated Shibboleth-core
 
* updated Shibboleth-core
 +
* fixed NullPointerException introduced by an erroneous merge in v2.1.4-slo3
 
** [https://repo.niif.hu/gitweb/gitweb.cgi?p=java-shib-common.git;a=snapshot;h=9ca9935759326d14fb7044da13bf1a886861bf0a;sf=tgz java-shib-common]
 
** [https://repo.niif.hu/gitweb/gitweb.cgi?p=java-shib-common.git;a=snapshot;h=9ca9935759326d14fb7044da13bf1a886861bf0a;sf=tgz java-shib-common]
** [https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git;a=snapshot;h=d1a9c031f89c5798ee401f84c3fbbf588cb1a3e7;sf=tgz java-idp]
+
** [https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git;a=snapshot;h=eb7b7e3ddbadb21fcb819f0b2458593657046df9;sf=tgz java-idp]
  
 
==== v2.1.3-slo3 ====
 
==== v2.1.3-slo3 ====

A lap 2009. október 19., 12:07-kori változata

Features

  • Implements SAML2 Single Logout profile
  • 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.
  • Highly customizable front-channel logout interface which leverages javascript and asynchronous operations in order to provide a clean, simple UI.
  • UI is usable with javascript disabled.
  • Supports localized SP name lookup via Organization elements in SAML metadata .
  • Fallback to back-channel logout if front-channel is not supported by the SP.
  • Supports Shibboleth SSO sessions (if the SP initiates sessions using Shibboleth1.3 protocol, but supports SAML2 logout).
  • Supports full back-channel operation.
  • Supports IdP-initiated Single Logout.

UI customization

The UI is located in two JSP files:

  • sloQuestion.jsp the user chooses whether she wants to logout from all service providers or just from the provider where she came from.
  • sloController.jsp is the logout UI where every session participant and their corresponding logout status is shown. At the end of the logout process, the user is notified if the single logout was completed.

How it works

SLOServlet

The heart of the logout process is the SLOServlet. This servlet is responsible for these actions:

  • rendering the logout question and controller page
  • initiating front-channel or back-channel logout to one SP (SLOServlet?action&entityID=...)
  • returning the logout status as a JSON string (SLOServlet?status)

With javascript

The controller renders a page where an iframe is placed for every active session participant. This iframe calls the SLOServlet?action&entityID=... 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).

The status of the single logout process is queried via asynchronous requests. The status response from SLOServlet is a JSON array. This JSON array contains one object with the entityID and logoutStatus properties for each session participant.

The logout status can be one of the followings:

  • LOGGED_IN: logout is not initiated for this participant yet.
  • LOGOUT_ATTEMPTED: logout was initiated.
  • LOGOUT_FAILED: logout failed.
  • LOGOUT_UNSUPPORTED: SAML2 logout is not supported by the participant (the metadata does not contain the necessary endpoints).
  • LOGOUT_TIMED_OUT: timed out waiting for a response.
  • LOGOUT_SUCCEEDED: logout was successful.

Status queries are issued using exponential backoff timing, until the timeout is reached. Please see the sloController.jsp for the exact timing used.

Without javascript

Controller renders an HTML page with <noscript> tags. There is one link for each session participant opening up in new window/tab, which can initiate the logout process for that particular SP. Depending on the current logout status, several other controls are enabled on the page:

  • Refresh button, which will reload the controller HTML with the current status icons to follow the overall logout process.
  • Logout failed message when logout process was finished, and there was at least one failed session participant.
  • Logout succeeded message when logout process was finished, and all session participants completed the logout.

IdP-initiated Logout (available since v2.1.3-slo2)

The user can initiate their logout process from the IdP (the URL is /idp/Logout). IdP-initiated logout has a clear advantage over SP-initiated logout, because the URL and the UI is fully independent from the current SP software used, thereby providing a unique logout URL for all users of the given IdP.

Non-trivial settings

Security

SAML Single Logout Profile requires the logout requests and responses to be signed or otherwise authenticated. Without this, a user session could be DOS-ed knowing the NameID.

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

Signing can be turned on by setting the signing property to front (for front-channel only) or true in the ApplicationDefaults or ApplicationOverride element in shibboleth2.xml.
Note: Signing messages 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 CA) than the SP (possibly self-signed, client certificate). Therefore the SP must sign back-channel messages as well to authenticate itself to the IdP. Unfortunately, you can only enable signing all (otherwise transport protected) messages, and this may affect performance.

Not requiring peer authentication

Message issuer authentication can be turned off by changing the security policy of processing Single Logout messages. You can do this by commenting out the following line from the block SAML2SLOSecurityPolicy at relying-party.xml:
<security:Rule xsi:type="security:MandatoryMessageAuthentication" />

Session lifetime

IdP session lifetime must be longer than any SP session lifetime. Otherwise, if an SP session outlives the IdP session and the user reauthenticates for a new session for other SPs, logout would not terminate session at the first SP.

The IdP can limit the maximum lifetime of the SP session by using the (optional) SessionNotOnOrAfter property in the SAML2 authentication statement. SAML1.1 does not have this feature, so you cannot limit the session lifetime for SPs using Shibboleth SSO protocol.

This can be set in the relying-party.xml by specifying the number of milliseconds in the maximumSPSessionLifetime attribute of the SAML2SSOProfile configuration.

Required changes in the IdP

Name identifier caching in IdP session

In the LogoutRequest the IdP must reference the current user's name identifier. This name identifier is issued as part of the SSO process. In order to efficiently retrieve this information, the IdP should cache the name identifier in the IdP session information object.

Associated ticket: SIDP-336

Session indexing

On receiving a LogoutRequest from a session participant, the IdP must be able to retrieve the IdP session associated with the principal. Session participants use the issued name identifier to identify the principal. The IdP session object can be indexed (and then retrieved of course) by any arbitrary unique key, so we use the name identifier value to index the session.

Associated ticket: SIDP-338

IdP Session invalidation

Currently there is a bug in the IdP implementation which causes the IdP sessions to outlive the session removal.

Associated ticket: SIDP-333

How to use

How to build

  • install the maven2 build tool
  • source code is available from our git repository
    • you can use the convenient snapshot links below to start playing
    • if you are brave enough, feel free to clone the whole repository and track our development branches (frontchannel-slo for the idp project and slo-configuration branch for the shibboleth-common project)
  • compile the shib-java-common project first with the mvn -DskipTests install command (the first build might take quite a long time if you haven't used maven before)
  • compile the java-idp project with the same maven command
  • install the java-idp/target/shibboleth-identityprovider-{version}-bin.zip binary package the same way as you'd install a vanilla Shibboleth IdP bundle

Released versions

v2.1.4-slo4

  • updated Shibboleth-core
  • fixed NullPointerException introduced by an erroneous merge in v2.1.4-slo3

v2.1.3-slo3

v2.1.3-slo2

v2.1.3-slo1

  • support SP initiated front- and back-channel logout

Hints

  • Don't forget to include Single Logout endpoints in the IdP metadata
  • Shibboleth SP prior to 2.1 did not include NameID properly in the LogoutRequest, therefore you cannot initiate SLO with Shibboleth SPs older than 2.1
  • Shibboleth SP prior to 2.2.1 answered with Partial logout for back-channel requests due to a bug
  • Shibboleth SP (currently released versions) do not distinguish between Success and Partial logout when showing the UI (see this report for details). This is not needed unless you are using back-channel logout.
  • If you plan to upgrade a clustered IdP to this version, don't forget to check the new tc-config.xml and rebuild the terracotta boot jar

Missing features

  • Administrative logout
  • Logout the user in the underlying JAAS provider