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.




Comments:

Hello Hubert,

I'm looking at different implementations of OpenID.

Could you tell us what happens after step 5? Once the principal is authenticated and the RP has verified the SSO message. This is the place where OpenID stops and a session starts.

In the OpenID implementations I've seen, usually at this step, the RP gives the user a cookie which will be used as proof of authentication during the session. They do this to avoid the performance and lag cost that would represent having to do steps 2-6 for each request.

My specific question is if you're using cookies after step 5 and, if yes, how are you protecting your cookies? Are all the transactions where this cookie is transmitted done on top of SSL?

Many thanks,

-jose

Posted by jose on December 07, 2007 at 12:33 AM PST #

Hi Jose,

Our OpenID implementation is a module for Sun Access Manager (http://www.sun.com/software/products/access_mgr/) - the open source version of it being OpenSSO (href="https://opensso.dev.java.net/).
AM is the one performing session management and yes you guessed right we do use a session cookie for that. That sesssion cookie carries an encrypted token, called sessionID, which contains information about the current session. In addition to encrypting the session cookie we do recommend to take measures to prevent session-cookie hijacking. I highly recommend you read this article (http://docs.sun.com/app/docs/doc/819-7849/gdqym) that describes both what the problem is and you can avoid it with AM (or OpenSSO).

Hope this helps!

Hubert

Posted by Hubert on December 07, 2007 at 01:53 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

hubertsblog

Search

Archives
« April 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
   
       
Today