A Quick Review
Wouldn’t it be nice if we didn’t have to remember so many passwords? With the proliferation of Software as a Service (SaaS) applications on the internet there are more and more things that we need to remember a username and password to access. This is where Single Sign-On (SSO) comes in. Single Sign-On is the idea that you can sign-on with one set of credentials and be signed-on to multiple services all at once.
In Part 1 we covered some of the basics of what Single Sign-On is and how we send end-users off from our site to their Identity Provider to verify their identity.
Getting the Id Back
Once the user has successfully logged in to their Identity Provider and decided to allow our site to know what their identity is, the user will be returned to the call back URL that we specified with the necessary information in browser. We just need to verify it and decide what to do next.
In Part 1 we told the Identity Provider to send the end-user to a script called call_back.php to complete the process of logging in the user. Lets start writing that script:
// See the examples/consumer/common.php file in OpenID Enabled library package.
// This provides some utility functions used below.
require_once 'common.php';
session_start();
// Create a new OpenID consumer to receive our Identity Provider response.
// To create the consumer we need to setup a store for the OpenID information
$store_path = '/tmp/_php_consumer_test';
$store = new Auth_OpenID_FileStore($store_path);
// Once we have a store for the information we need to create a new consumer.
$consumer =& new Auth_OpenID_Consumer($store);
// The GApps_OpenID_Discovery allows the consumer to find openid's for Google Apps.
new GApps_OpenID_Discovery($consumer);
// To complete the discovery process we need to pass the same callback url that we sent to the Identity Provider.
// This ensures that we can check the signature the Identity Provider sent us.
$server_url = 'http://myserver:80';
$response = $consumer->complete($server_url.'/callback.php');We now have the response from the Identity Provider. With the response we can now check the status of the OpenId discovery and get the returned OpenId.
$openid = '';
switch($response->status)
{
case 'success':
$openid = $response->endpoint->claimed_id;
break;
case 'cancel':
case 'failure':
case 'setup_needed':
default:
// If we got a status we don't understand we should take an appropriate action.
break;
}
if (!empty($openid))
{
// We have an openid, we need to check if it's associated with a login in our system.
}
else
{
// We didn't get an openid, generate an error
}What you do with the OpenID once you have it is dependent on how you handle logins on your site. You could check to see if the OpenID is already associated with an account on your site and if not then prompt the end-user to create a new account. In our case we only want to associate OpenID’s with existing end-user accounts. We store the OpenID in our database with an association to an existing account. If the OpenID is not associated then we prompt the user to enter their existing credentials (loging them in) so we can associate their OpenID with their account.
Round Up
Implementing Single Sign-On allows your users to access their data using one set of credentials, rather than having to remember a different set of credentials for each site. This means they can remember fewer more secure passwords rather than have to remember more less secure passwords (or use the same password across many sites).
For SaaS applications that target businesses implementing SSO with Google makes it possible for you to get your application listed in the Google Apps Marketplace. This gives your application access to over 2 million businesses that use Google’s enterprise applications.
{ 2 comments }
