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:
- The user visits a web site (relying party - RP) that requires authentication. The web site being OpenID enabled, the user enters her OpenID identifier.
- The RP retrieves the corresponding html page. That page contains information on where the OpenID@Work provider (OP) is.
- The RP redirects the user's browser to the OP
- OpenID@Work performs authentication of the user
- 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:
- 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.
- The user visits the RP and provides his/her OpenID ID (the URL).
- The RP obtains the URL from a web server instance (HTTP based) that only serves OpenID IDs (and FAQs)
- The RP talks to the OpenID module (an extension to OpenSSO) to create association key etc.
- 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.
- 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.