Decoupling Authentication with Federation Standards

Identity Federation lets you leave all of these authentication issues to a third party (an Identity Provider) that builds their business on managing authentication. You can pick one or more identity providers to 'trust' with your users. You then focus on your core application, and let them authenticate your users for you. This not only saves you work up front and removes risks of password attacks, it gives your users single sign-on capability and gives you more flexibility down the road.

The next question is -- how will you communicate with these identity providers? You can choose a proprietary federation mechanism tied to a single identity provider (for example, Facebook Connect).

You have many more options, today and in the long run, by selecting standards-based federation protocols like OpenID or SAML. The protocol you choose will depend in part on your platform and the target audience for your application.

• OpenID is a free, decentralized system for implementing a single digital identity online. Today, it is used mostly in the consumer space, and is being adopted by retail and community sites. Google, Yahoo and AOL can all serve as OpenID identity providers.
• SAML or the Security Assertion Markup Language is more widely used in business applications. Google Apps and Salesforce, for example, both support SAML-based single sign-on. And Microsoft's Active Directory Federation Standard (ADFS) supports SAML.

Whether you use OpenID or SAML, the process is similar. Your application exchanges identity assertions with other applications, typically trusted identity providers or partners. The Identity Provider (IdP) authenticates the user. Your application is a 'service provider' or identity consumer (the terminology varies with the protocol). It consumes or accepts the identity assertions of the provider. Your application only needs to maintain the list of the providers or partners that you trust when it comes to user identity.

What Do You Get In Return for Deploying These Standards?

Rapid deployment. While there may be some initial work in selecting the federation standard and deciding how to deploy it, this approach is significantly faster than doing authentication right -- with secure processes for password reset, separation of accounts and passwords, and adequate security for the account information.

You can choose enterprise identity solutions or open source solutions. You can even use Web-based services like myOneLogin Federation to completely decouple the federation process from your service. In this case, adding federation to your application becomes nothing more complex than adding a few simple calls to a Web-based service:

    // Setup SOAP call to validate authentication assertion 
    $client=new SoapClient( $wsdl ); 
    $param = array ( 
        "samlResponse" => $saml, 
        "recipientName" => $self 
    ); 

    //  SOAP call validate authentication assertion
    try { 
        $response = $client->validate( $param ); 
    } catch ( Exception $e ) { 
       echo 'web service call failed, add error handling here'; 
       exit; 
    }

echo "login successful for" . $response->return->username . "\n";

Password security isn't your problem. Let's say that despite your best security architecture, determined hackers gets into your site. They won't be able to glean accounts and passwords that they can then use to access your application undetected, or to access other applications that may share the same passwords, because that data isn't stored anywhere in your application. Authentication security is now the IdP's responsibility, not your's. Oh, and you don't have to worry about password reset logic -- again, it's not your problem anymore.

Automatic Web SSO. If you have multiple Web applications, then using federation standards automatically gives your users single sign-on (SSO) across them. You can also create communities with partners by enabling federated logins across your different applications.

IdPs can provide strong authentication. If your Web application hosts sensitive data (financial information, customer data, regulated data), your users may well want to add another layer of security to the authentication process beyond a password. Multi-factor authentication is more difficult for attackers to defeat.

There are many ways to add authentication factors, from browser certificates and cookies through tokens and smart cards to biometrics. There is no single "right" multi-factor authentication choice -- it will depend on multiple factors, including cost, convenience, user community profile, and the changing threat environment.

Strong authentication is an industry in and of itself -- far beyond the scope of what you might want to undertake within your own Web application unless you happen to be in the security/identity market. If you're using federation, however, you can select identity providers that have already done the hard work of supporting different authentication credentials. You can pick and choose the identity providers based on their authentication strength, and offer your users a range of options for access security.

Pick, choose and change IdPs as needed. Letting IdPs do the authentication improves your agility. If authentication isn't built into your application, you can change or strengthen authentication processes on the fly. This can some at the request of your users or as the threat environment changes. And you can make those changes in minutes, not days, weeks or months of development time.

Auto provisioning. Using federation to authenticate users opens up other possibilities -- like auto provisioning with trusted users. The SAML federation standard, for example, can pass a number of user attributes as part of the identity assertion. Using this as a foundation, you can choose to work with trusted partners to allow automated provisioning within your application.

For example, you can work with a partner to identify the user attributes you need to provision a user within your application. When a user on the partner's application chooses a link to your application, the identity assertions pass the necessary information. Your application, upon receiving that data, first checks to see if the user has an account and if not, provisions the user within your application.

Clearly the reverse holds true as well; you can send users to trusted partners who will then provision the user within their application if necessary. You remove barriers to new users while supporting seamless single sign-on between your partner applications.

Summary

Web applications have rapidly become the standard interface for everything, from our personal finances and social interactions, to business processes. And that's putting new pressure on old methods for authenticating. As a developer, you have to rethink how you handle authentication processes, and whether you're really willing to take on the full responsibility for authentication in an increasingly interconnected Web.

Happily, you've got some new options in identity federation standards like OpenID and SAML. They're gaining traction rapidly, as major software vendors and Web applications alike are going beyond lip service to a real commitment to interoperability.

You have multiple choices for deploying those standards, from writing your own calls to using external web-based services. And you can leave the entire user authentication issue to a third party identity provider that is willing to undertake the security issue -- avoiding altogether identity management issues within your own application.

<?php
   /**
    * Note that this is just a proof-of-concept.
    * Be sure to test and cleanup for deployment.
    *
    * This example expects a POST of a base64 SAML assertion.
    * The SAML is validated using the myOneLogin web service.
    * Validation is done against page itself (see $self below)
    * and displays the username on success, and error message
    * on failure.
    */

    // Build our own URL, to be used for validating SAML destination
    $self = 'http';
    if ($_SERVER['HTTPS']) {
		$self = $self.'s';
	}
	$self = $self.'://'.$_SERVER['SERVER_NAME'].$_SERVER['PHP_SELF'];

    // PHP has to be configured with SSL
    $wsdl = 'https://developer.myonelogin.com/SAAS/API/1.0/SOA/validateSaml?wsdl';

	// Extract SAML response to validate
    try {
       $saml = $_POST["SAMLResponse"];
       $target = $_POST["TARGET"];
    } catch ( Exception $e ) {
       //log_error "Missing parameters";
       exit;
    }

	// Do PHP5 SOAP call to myOneLogin web service
    $client=new SoapClient( $wsdl );
    $param = array (
        "samlResponse" => $saml,
        "recipientName" => $self
    );

	// Call validate method, send SAML and successRedirect
    try {
        $response = $client->validate( $param );
    } catch ( Exception $e ) {
       echo 'web service call failed, add error handling here';
       exit;
    }

    /**
     * The response is an object containing a result object with the following members:
     * valid - bool whether or not the saml response was valid
     * message - String useful for determining why a saml response was found invalid
     * username - String for whom the saml response was issued for (if valid)
     */
    if ($response->return->valid == true) {
       // At this point session can be setup as authenticated,
       // and request forwarded to actual protected target.
       echo $response->return->username;
    } else {
       // At this point, an error message should be displayed.
       echo $response->return->message;
    }

    exit;
?>