Thursday Jun 14, 2007

OpenID @ Work - Infrastructure Description

In my previous post I described our OpenID@Work overall architecture and flow. In this post I describe the deployment we adopted for this. A picture being worth a thousand words, here's an illustration of our deployment:

All traffic arrives through a load balancer that also serves as firewall and SSL terminator. The servers behind the firewall are run on a VIP. Server 1 runs Web Server 7 (more info here) on which we run the 2 instances of OpenSSO, the OpenID extension and the OpenID pages server (see previous post for details). Server 2 is a mirror of Server 1, mostly for load balancing and failover if needed. The users accounts are stored mirrored LDAP servers (servers 3 & 4). We use Sun Directory Server and plan to move to OpenDS soon.

For those of you interested, our servers specs are:

x2200 M2 with the following specs:
- 2 dualcore AMD Opteron Model 2218
- 8GB RAM (4x2GB DIMM)
- 2x250GB SATA HDD

Wednesday Jun 13, 2007

OpenID @ Work - Architecture

We finally officially launched our OpenID@Work identity provider for Sun employees (last week)!

I now have some time to describe in more details what we our service is and its architecture. This blog entry will describe the architecture we have put in place and to some extent explain our choices.

First off, here's a high-level overview of the OpenID protocol flow.

The steps are as follows:

  1. The user visits a web site (relying party - RP) that requires authentication. The web site being OpenID enabled, the user enters her OpenID identifier.
  2. The RP retrieves the corresponding html page. That page contains information on where the OpenID@Work provider (OP) is.
  3. The RP redirects the user's browser to the OP
  4. OpenID@Work performs authentication of the user
  5. Upon successful authentication, the user's browser is redirected to the RP and logged in.

Now back to Sun's OpenID deployment. Below is the list of constraints we put on this deployment:

  • The OpenID@Work service is only for Sun employees.
  • This is an opt-in program so Sun employees that want a Sun OpenID need to register.
  • OpenID@Work is an OpenID provider, not a relying party.

Now onto the architecture of our deployment. The figure below describes the overall architecture of our deployment.


The steps are the following:

  1. Registration phase - the user needs to go through a specific phase to register and obtain his/her Sun OpenID ID. The main difference with a standard registration is that Sun needs to make sure the principal is indeed a Sun employee. I'll describe those steps later on. This step leverages the OpenSSO's Membership module and is run in a separate instance.
  2. The user visits the RP and provides his/her OpenID ID (the URL).
  3. The RP obtains the URL from a web server instance (HTTP based) that only serves OpenID IDs (and FAQs)
  4. The RP talks to the OpenID module (an extension to OpenSSO) to create association key etc.
  5. The RP redirects the principal's browser to the OpenID instance for authN. The OpenID module will communicate with the second OpenSSO module and, if there is no valid session, OpenSSO will prompt the principal for authentication.
  6. The principal can at anytime log into the second OpenSSO instance to manage his/her profile (e.g. change password etc.).

In my next postings I will describe in more details some of the aspects mentioned above.

Monday May 07, 2007

OpenID at Sun

This is what I've been working on for the last (many) weeks:

Sun is deploying an OpenID enabled Identity Provider (OP in OpenID jargon) for its employees. Any Sun employee will be able to create an OpenID identifier and use it with OpenID enabled relying parties (RP).

Our primary objective is to figure out adequate uses of OpenID in the enterprise context. As SAML and Liberty supporters we know OpenID (1.1) is addressing a different market when it comes to delegated authentication. Its lack of trust establishment between the IdP and the RP is, in my opinion, one of the challenge OpenID is facing in a B2B scenario. By placing the IdP within Sun's DNS and controlling the OpenID identifier format we inject some of that trust in the authentication process. Consider the scenario where a company that does business with Sun offers a discount to Sun employees. In order for me to have access to the employee discount pages at their web site, Company A, in addition to my identity needs to know that I am indeed a Sun employee. I think combining OpenID and a certain for of trust of the IdP is ideal for that kind of scenario.

Our OpenID deployment (1.1 & Simple Reg.) is based on the module that was recently written by Paul Bryan as part of our open source effort OpenSSO. In my next blogs, I'll be posting a lot of tips and howtos directly related to this deployment.





« July 2016