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.




About

hubertsblog

Search

Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today