Identity federation and OpenId

Identity federation is a hot subject at this moment, at least for my customer.

It began innocently enough: someone who did not belong to the organization needed to access an application. “Not a problem”, let’s register him. Some year later, needs number in thousands of users, and the identity management has outgrown its capacities: the software was sized for the organization, not for the myriad of third-party users around it. And yet, partners, customers and providers, they all have very valid reasons to access internal applications, but still have to be identified and given rights (authentication and authorization), like any other user.

It’s one of those use-case where identity federation fits in. What’s identity federation anyway? Wikipedia defines it as:

“A user’s authentication process across multiple IT systems or even organizations.”

I’d rather define it as a user’s authentication across multiple domains. Domain may refer indifferently to coarse-grained or fine-grained systems.

Other use-cases of identity federation include:

• a startup which has no desire to invest in any identity management software (acquired or developed), and prefer to delegate to a third-party
• an organization that need “fresh” information about identities will delegate to a third-party where this “freshness” is almost garanteed, whether for legal reasons or just because
• an decentralized organization which delegates authentication to its units but still needs its applications to be interoperable
• etc.

A great advantage of identity federation is that it’s the basis of Single Sign-On. This feature becomes more and more in demand as the number of available applications grow: either users forget their login/password or they note it somewhere which defeats security.

Anyway, identity federation takes a greater importance nowadays, even if previous technologies provided some capabilities oriented toward it. I’m thinking about LDAP here, where you can host some branch of your LDAP tree on another LDAP. This is limited, however, because master and delegate must still share the same schema (if I remember well, I haven’t played with LDAP in a long time).

With such increased need toward identity federation, it’s only natural that there’s plenty of solutions around but no clear standard, either normalized or de facto. Available technologies include (but are not limited to): CAS, Shibboleth and OpenId. I recently became interested in the latter, not because it’s better than the others (I’m new in this field and have not enough input to pass such judgement) but because Google is an OpenId provider in front either of Google’s own id management or Google Apps‘s. This means you can manage your identities on Google infrastructure (and it’s free up to 50 accounts) and authentify your users with it using OpenId!

Authentication with OpenId is a multi-step process:

1. Application gets available authentication endpoints from a provider
2. Application redirects the user to one of such authentication endpoint
3. User authenticates himself on the provider infrastructure
4. Provider redirects the stream to the application if successful
5. Finally, application checks whether authentication was successful

Luckily, there’s a OpenSource project available in Java that nicely wraps the gritty details of OpenId inside an API. This project is aptly named OpenId4Java and works like a charm.

The first two steps are handled by the following code:

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
 
  try {
    // API entry point
    ConsumerManager manager = new ConsumerManager();
 
    // Get available endpoints
    List<?> discoveries = manager.discover("https://www.google.com/accounts/o8/id");
 
    // Bind to endpoint
    DiscoveryInformation discovered = manager.associate(discoveries);
 
    // Create the auth request, providing return URL
    AuthRequest authReq = manager.authenticate(discovered, request.getRequestURL().toString());
 
    // Redirects to provider login page
    response.sendRedirect(authReq.getDestinationUrl(true));
 
  } catch (Exception e) {
 
    throw new ServletException(e);
  }
}

Just trying the previous code will get our user to a Google’s login page! Once the user is authentified, he’s sent back to our application: we just have to manage the token to verify its integrity. OpenId4Java also does the trick (previous code must be slightly modified, you’ll find it in the sources):

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
 
  ParameterList openidResp = new ParameterList(request.getParameterMap());
 
  DiscoveryInformation discovered = (DiscoveryInformation) request.getSession().getAttribute("discovered");
 
  StringBuffer receivingURL = request.getRequestURL();
 
  String queryString = request.getQueryString();
 
  if (queryString != null && queryString.length() > 0) {
 
    receivingURL.append("?").append(request.getQueryString());
  }
 
  try {
 
    VerificationResult verification = manager.verify(receivingURL.toString(), openidResp, discovered);
 
    Identifier verified = verification.getVerifiedId();
 
    if (verified != null) {
 
      AuthSuccess authSuccess = (AuthSuccess) verification.getAuthResponse();
 
      request.getRequestDispatcher("/WEB-INF/page/welcome.jsp").forward(request, response);
 
    } else {
 
      request.getRequestDispatcher("/").forward(request, response);
    }
 
  } catch (Exception e) {
 
    throw new ServletException(e);
  }
}

Even better, Google supports an OpenId extension, the Attribute Exchange extension (AX). This let us query information about the user from theOpenId provider, provided we get the user’s agreement, of course. OpenId4Java seamlessly integrates with such an extension, we just have to update somewhat both our request and our response:

FetchRequest fetch = FetchRequest.createFetchRequest();
 
fetch.addAttribute("Email", "http://schema.openid.net/contact/email", true);
fetch.addAttribute("FirstName", "http://axschema.org/namePerson/first", true);
fetch.addAttribute("LastName", "http://axschema.org/namePerson/last", true);
fetch.addAttribute("Country", "http://axschema.org/contact/country/home", true);
fetch.addAttribute("Lang", "http://axschema.org/pref/language", true);
 
authReq.addExtension(fetch);

if (authSuccess.hasExtension(OPENID_NS_AX)) {
 
  MessageExtension ext = authSuccess.getExtension(OPENID_NS_AX);
 
  if (ext instanceof FetchResponse) {
 
    FetchResponse fetch = (FetchResponse) ext;
 
    request.setAttribute("EMAIL", fetch.getAttributeValue("Email"));
    request.setAttribute("FIRST_NAME", fetch.getAttributeValue("FirstName"));
    request.setAttribute("LAST_NAME", fetch.getAttributeValue("LastName"));
    request.setAttribute("COUNTRY", fetch.getAttributeValue("Country"));
    request.setAttribute("LANG", fetch.getAttributeValue("Lang"));
  }
}

With OpenId and OpenId4Java, using identity federation is really a matter of minutes!

You will find here the sources of the example project in Eclipse/Maven format.

To go further:

• Federated Login for Google Accounts
• OpenID 2.0 Java Libraries