Superpatterns Pat Patterson on the Cloud, Identity and Single Malt Scotch

24Jan/068

Sun Eats Its Own Liberty Dog Food

One question that I'm often asked by customers is "How is Sun using the Liberty Alliance Project specifications?". Well, my stock answer is 'BIPAC'. The Business Industry Political Action Committee provides expert policy analysis, research and communications on campaigns and elections, and fosters business participation in the political process. Sun employees can access political information on the BIPAC website - who their elected representatives are, their voting record etc.

Now, this is obviously sensitive stuff, with huge implications for privacy. The 'old way' of accessing BIPAC would have involved a regular batch process to synchronize identity information from Sun to BIPAC; Sun employees would authenticate at BIPAC with their Sun ID and a BIPAC-specific password. In this old model, BIPAC would know exactly who I was and would be able to build a profile of my activity on the site. Not only that, I'd have another password to write on a post-it note and stick to my monitor remember.

The 'new way' of accessing BIPAC authenticates employees at Sun (using Sun Java System Access Manager) and uses Liberty ID-FF to give employees single sign-on to BIPAC. Now - here's the clever bit - no personal information is transmitted in the single sign-on process. BIPAC have no idea who I am - all they know is that I am an authenticated Sun employee. BIPAC can then use ID-WSF to retrieve a strictly limited set of attributes, including my zip code. So now, all Sun know is that I am a Sun employee in 90210 (well, I can dream). They have everything they need to tell me who my elected representatives are at every level up to Dubya, but no more. They don't know who I am, since they don't need to know who I am. This document gives some more detail on the deployment. Here I am demonstrating the system at a Liberty eGovernment Forum last year in Dublin:

Looking at the wider context, this was an ideal first deployment of Liberty for Sun. A real need for Liberty's privacy features combined with low risk - BIPAC is a valuable service, but not critical to Sun's core business. Watch this space for news as we roll Liberty and SAML out across Sun's other business partners, and, if you're at the RSA Conference next month, be sure to catch Sun's Yvonne Wilson at IMP-101 'Implementing Federated Identity: What Products Do You Need?'. Yvonne is an architect in Sun IT and will be covering our BIPAC integration in her presentation.

Comments (8) Trackbacks (0)
  1. Yvonne gave an excellent talk on this subject at XML 2005. The proceedings paper is available and contains lots of details such as business benefits, architecture, and some of the issues that were faced and how they were solved.
    http://www.idealliance.org/proceedings/xml05/abstracts/paper154.HTML

  2. One clarification. There is still a regular batch feed from Sun to BIPAC to provision and link accounts in bulk, but this feed no longer contains any personally identifiable information (PII), so no usernames, no passwords. It enables BIPAC to set up accounts in their system so they don’t have to go through a new account provisioning step when user EIO37832HJD (i.e. a Sun employee identified only by an opaque pseudonym) arrives via single sign-on.

    Bulk federation in this manner is the norm when a federated account has no ‘life’ outside the federation – i.e. Sun employees have no independent username and password to access BIPAC outside the context of the federation.

  3. Single sign on means (to me anyway) using
    two different authenticated websites and only
    needing to log in once.
    How is BIPAC (by itself) demonstrating SSO?
    I understand that BIPAC is using the L.A.
    credential interfaces, and that’s great. It’s
    nice to see us eating our own dog food.
    But I doesn’t really get the consumer anything
    until it really provides real SSO abilities.
    –chris

  4. Hi Chris,

    Here’s the deal. You have a session on SunWeb. Clicking on a link to BIPAC will use the Liberty ID-FF protocols to single sign-on to BIPAC. As far as you, the end user are concerned, clicking the link brings up a web page at BIPAC that says something like ‘Welcome Sun Employee in 95124’ with the relevant information for your home zip code. No login at BIPAC required.

  5. SSO in the braoder sense may be nice, but a happy CPO is much nicer. Sun’s CPO is very happy to have one less vendor with sensitive employee data– they didn’t need it & I didn’t want to give it.
    Sun’s Liberty enabled products helped me sleep thru the night on this one!

  6. It is important to note that the site is tailored for Sun employees, with information on how these elected officials voted on issues that are important to the company. In other words, this isn’t just an external site that provides information that anyone can get, it’s a site that is specifically for Sun employees, created in conjunction with Sun’s Public Policy Dept. I think this shows the power of Liberty to enable this kind of functionality that is both targeted and privacy preserving. It demonstrates the value of the two groups working together using the Liberty technology.

  7. Pat, it’s a scary thought in some ways, but in other ways reassuring: that Dublin workshop was in *April 2005*! You’ve had this stuff working for quite a while now.

  8. Even more scarily, we did the integrated identity management demo for the SunNetwork conference in Beijing in June 2004. That was a doozy – Access Manager protecting an enterprise portal in which you could create new accounts in an HR system which Identity Manager then provisioned into Directory Server so that the newly provisioned user could log into the portal and then (still with me?) access a partner website via SAML 1.1. I’ll have to see if we can post an annotated version on the web. That’s still a killer demo of how the Sun products stack together.


Leave a comment

No trackbacks yet.