Single Logout: A Demo

Print-friendly Version

This article keeps that promise. You'll learn how Project Lightbulb has grown, what constitutes a Circle of Trust, and how SLO works.

Soon after the release of the initial Project Lightbulb implementation, OpenSSO developers championed other variations by way of extensions:

• A Ruby implementation of SAML 2.0
• An OpenID identity provider (IdP), now deployed as part of openid.sun.com
• A PHP client SDK for OpenSSO

Accordingly, the Lightbulb name, which denotes the extension of the Linux/Apache/MySQL/PHP-Perl-Python (LAMP) stack, no longer applied to this growing community. After much debate, the project participants decided on the name OpenSSO Extensions to capture the modules that build on the access control, SSO, and federation technologies in OpenSSO but that are not part of the core project. Hence, even though OpenSSO operates under a governance model, including a formal review of all submitted code, OpenSSO Extensions conforms to a more liberal policy that allows development of small, experimental modules.

Simultaneously, Project Lightbulb, now called the SAML 2.0 PHP Relying Party, has been much enhanced and extended, most notably by Andreas Solberg of the Feide Project in Norway. In addition to restructuring the original code for extensibility, new features, and bug fixes, Andreas has written an excellent user's guide—a must read before you deploy SAML 2.0 PHP Web applications.

Although not defined in the SAML 2.0 Specification, the concept of the Circle of Trust works wonderfully well with federation in general and SAML 2.0 in particular. The Liberty Alliance defines a Circle of Trust as "the many business, legal and privacy policies that govern federation both within an organization and among all of the participants in the federated network." A simpler definition might be "a group of organizations that have agreed to make life simpler for their shared end users."

Consider the example of an enterprise with outsourced functions such as Human Resources. Employees simply log in to the intranet and can then immediately access their personal data at the external HR provider's site without another login step. In fact, that is exactly how Sun Microsystems employees now access their outsourced HR system at Hewitt Associates.

The simplest Circle of Trust comprises a single IdP and one or more SPs. Through SSO, users authenticate at the IdP to access the SPs' resources, as described in the Project Lightbulb article. An excellent white paper by Sun and Nokia, Identity Federation and Web Services: Technical Use Cases for Mobile Operators (PDF), offers numerous examples—from simple ones such as the one cited in the Project Lightbulb article to complex use cases that involve multiple Circles of Trust. The examples apply to all industries, not just to mobile operators.

SLO, a key capability of SAML 2.0, was inherited from its predecessor, Liberty Alliance's Identity Federation Framework. By authenticating at an IdP, a user establishes a local session there. As mentioned in the Project Lightbulb article, the user can establish a local session with each of several SPs by means of an authentication response according to SAML 2.0's SSO protocol.

Because the IdP keeps track of the SPs to which it has sent an authentication response, when a user logs out from one SP, the IdP can notify the other relevant SPs. That means, conveniently, the user can log out of all the sessions with only one click.

In some cases, a user might access a set of resources spread across several disparate providers. However, the seamlessness of SSO and SLO accords the impression that the user is visiting several resources at a single provider, not several providers. Simplicity rules!

Figure 1 illustrates an example of the SLO process as defined by SAML 2.0 and implemented in the SAML 2.0 PHP Relying Party. Here, when the user initiates SLO at an SP, the IdP sends the SLO messages according to SAML 2.0's HTTP Redirect binding.

Figure 1: Process of SLO

Following is the process:

1. The user initiates SLO at service provider 1 (SP1), perhaps by clicking a Logout link.
   
   
2. SP1 redirects the browser to the IdP with a 302 HTTP response.
   
   
3. The browser follows the redirect and sends an HTTP GET request to the IdP with a SAML logout request encoded in an HTTP parameter.
   
   
4. The IdP redirects the browser to SP2 with a 302 HTTP response.
   
   
5. The browser follows the redirect and sends an HTTP GET request to SP2 with a SAML logout request encoded in an HTTP parameter.
   
   
6. SP1 redirects the browser to the IdP with a 302 HTTP response.
   
   
7. The browser follows the redirect and sends an HTTP GET request to the IdP with a SAML logout response encoded in an HTTP parameter.
   
   Steps 4-7 are repeated for each SP to which the user has logged in.
   
   
8. The IdP redirects the browser to SP1 with a 302 HTTP response.
   
   
9. The browser follows the redirect and sends an HTTP GET request to SP1 with a SAML logout response encoded in an HTTP parameter.
   
   
10. SP1 reports successful logout.

For other scenarios, see the SAML 2.0 Profiles Specification (PDF).

To explain the process in detail, this section follows the protocol through the PHP code. The sample application resides in the example-pat directory of the SAML 2.0-PHP project.

Initiating SAML SLO
To log out, the user clicks a link on the sample's main page, home.php, which invokes the logout script, logout.php. If the user accessed the sample through SSO, the logout.php script redirects the browser to the spSLOInit.php script, which reads as follows:

if ( federatedLogin() ) { 
    header("Location: " . $LIGHTBULB_CONFIG['baseurl'] .
"spSLOInit.php?RelayState=" . $_GET['RelayState'] );
} else { 
    // Process local logout 
    // ...
}

Table 1 describes the two related parameters.

Parameter	Description
RelayState	The URL to which to redirect the user when logout is complete.
binding	The SAML binding in the protocol for future use. Currently, SAML 2.0 PHP supports only the HTTP Redirect binding.

The spSLOInit.php script performs the following tasks:

1. Retrieves from the PHP session store the user's SAML authentication response, which originated from the IdP during SSO.
   
   
2. Extracts the user's NameID and SessionIndex values from the authentication response.
   
   
3. Creates a SAML LogoutRequest element that contains the NameID and SessionIndex values and other data.
   
   
4. Compresses (deflates) LogoutRequest, encodes the compressed data according to the Base64 encoding scheme, and URL-encodes the result.
   
   
5. Creates a URL with the encoded LogoutRequest and RelayState elements as the parameters for the IdP's SLO service endpoint.
   
   
6. Redirects the browser to that URL.

See this typical LogoutRequest element.

Processing LogoutRequest
On receiving the logout request, the IdP creates its own LogoutRequest element and sends it to the other SPs, redirecting the browser to each of the SPs in turn. Here is the message flow from the SP2 viewpoint, as processed by LogoutListener.php:

1. Decodes the Base64 SAML logout request and parses it and its component SAML Assertion with the—now slightly misnamed!—processResponse() function from saml-lib.php.
   
   
2. Invokes spi_sessionhandling_clearUserId() to terminate the local session.
   
   
3. Assembles a SAML logout response after compressing, Base64-encoding, and URL-encoding the XML element, as before.
   
   
4. Creates a URL with the encoded LogoutRequest and RelayState elements as the parameters for the IdP's SLO service endpoint.
   
   
5. Redirects the browser to that URL.

Processing LogoutResponse
Next, the IdP redirects the browser back to SP1 with another LogoutResponse element. Processing is performed by the SingleLogoutService.php script, which decodes and parses the response, terminates the local session (that is, logs out the user), or displays an error message, as appropriate.

SAML 2.0 bindings define the mapping of SAML messages to the lower-level protocols, such as HTTP or Simple Object Access Protocol (SOAP). The HTTP Redirect binding in the preceding example requires no direct connections among the providers: All communications are through the browser. However, direct connections might be necessary if the session state exists solely in the form of a cookie and thus requires direct interactions among the browser and the IdPs and SPs.

On the other hand, if any IdP or SP in the chain does not respond, the HTTP Redirect SLO sequence might fail, leaving active sessions at some SPs. To avoid that scenario, you can implement SLO with a SOAP binding, albeit at the cost of additional complexity in message encoding. The SAML 2.0 Specification (see References) details the SAML 2.0 bindings and their capabilities.

For good reason, many laud the OpenSSO SAML 2.0 PHP extension as exemplary open-source software. The past few months have seen the formation of a small yet effective community around it—a group of enthusiastic developers and architects who tested and enhanced the software. Even though that extension, unsupported by Sun, is still in an experimental stage, at least one enterprise is using it in production. As SAML 2.0 continues its progress toward becoming the standard federation protocol, more adoptions will likely materialize in the near future.

• Sun Java System Access Manager
  • Main page
  • Developer home
  • Software Forum
  
  
• SAML 2.0 Specification
  
  
• Project OpenSSO
  
  
• Related articles
  • Federated Identity: Single Sign-On Among Enterprises (October 14, 2004)
  • What's Happening in Identity at Sun (September 1, 2006)
  • Switch on SAML for PHP With Project Lightbulb
  
  
• Sun developer services
  • Support
  • Training and certification