OpenID (DOC) by leeonw




OpenID is an open, decentralized standard for user authentication and access control,
allowing users to log onto many services with the same digital identity. As such, it
replaces the common login process that uses a login-name and a password, by allowing
a user to log in once and gain access to the resources of multiple software systems. An
OpenID is in the form of unique URL, and is authenticated by the user’s OpenID provider
(that is, the entity hosting their OpenID URL).OpenID eliminates the need for multiple
usernames across different websites, simplifying your online experience.

What is OpenID?

OpenID is an open, decentralized, open-source framework for user-centric digital

Advantage for OpenID

OpenID takes advantage of already existing internet technology (URI, HTTP, SSL, and
Diffie-Hellman) and realizes that people are already creating identities for themselves
whether it is at their blog, photostream, profile page, etc. With OpenID you can easily
transform one of these existing URIs into an account which can be used at sites which
support OpenID logins.
OpenID is growing quickly and becoming more popular as large organizations like AOL,
Facebook, France Telecom, Google, LiveDoor, Microsoft, Mixi, MySpace, Novell, Sun,
Telecom Italia, Yahoo!, etc. begin to accept and/or provide OpenIDs.

How will I use OpenID?

OpenID solves the multiple accounts syndrome, but OpenID can do much more. For
example, you could achieve cross-application and cross-domain single sign-on (SSO). If
you log in to your blog and photo gallery using the same OpenID, you only need to
authenticate once with your authentication server. For each application that you need
to log in to after that (during the same session), you only need to provide your OpenID
instead of your username and password.
Who Supports OpenID?

OpenID is quickly gaining adoption amongst public consumption sites like Digg, Six
Apart, Zoomr and AOL, RPX.

Where can I use OpenID?

You can use your OpenID on any one of a growing number of sites (nearly fifty-
thousand) which support OpenID.

OpenID Protocol Overview

The OpenID Protocol is fairly extensive. The Sequence diagram shows the interaction
between the End User, Relying Party and the OpenID Provider for the most-common
authentication flow.
The process of logging a user into an external site has seven key steps:

   1. Relying Party acquires Identifier from the User

   2. 'Normalization': Relying Party cleans up the Identifier

   3. 'Discovery': Relying Party looks up how to communicate with OpenID Provider

   4. Relying Party establishes association with OpenID Server (Optional)

   5. Relying party requests authentication

   6. OpenID server responds to authentication request

   7. Validate the indirect response

RPX Provider Usage
RPX handles the UI, authentication, and import of user profile and registration data for
your website. It’s a Free open source OpenID Provider.


RPX makes it easy to add OpenID and other authentication APIs to your website. We
help you add authentication from providers like Google, Facebook, Twitter, Yahoo! and
Windows Live ID, making it extremely simple for users to get in and start using your web
application. RPX is a proxy between your website and the OpenID provider, and is
completely transparent to the end user.

The service looks like this from a very high level:
Adding RPX to your website doesn't require any changes to your database, and its only
requirements are the ability for your servers to make outbound HTTPS calls and to parse

RPX Flow

Below is a step-by-step diagram that shows how a user will sign in to your website using
RPX, including the appropriate integration points.

Step 1: User signs in from your website

The user chooses their identity provider from the sign-in interface, which submits the
form to the RPX server for processing. In this step you specify a token_url, which is
where RPX will send the user once they've been authenticated.

Steps 2-4: RPX handles authentication transaction

RPX starts the authentication on behalf of your website, and sends the user to their
identity provider. The provider authenticates the user and then asks for approval to
to your site.
Step 5: RPX sends the authenticated user back to your website

RPX sends the user to the token_url, with a token parameter.

Step 6: Use the token to access the authentication data

Your token_url handling code calls the RPX API with the token parameter, and gets back
an RPX response with the OpenID authentication information and profile data.

Step 7: Log the user in

Log the user into your website and create/update user profile with the data received in
step 6. The detail of how this is done depends on your website implementation.

Step 8: Optional - Map the OpenID to an existing user account

Map an OpenID to an existing account on your system. The mapping API is extremely
useful if you don't want to alter your database schema to accept RPX authentication, or
if you'd like to add multiple OpenIDs to a single user account.

The Sign-in Interface

RPX uses JavaScript to add a user friendly OpenID sign-in box to your website. This is the
sample sign-in box from the RPX Provider..
If the user wants to sign-in any one of the account, then it will redirected to our website.
Because before Register the application ,we will give the Policy URL as our website

Additionally, you may embed the interface directly into a page on your site without
using the JavaScript popup. If you would like to disable the pre-existing "Select one of
these third-party accounts" at the top of the embedded display, include the parameter
flags=hide_sign_in_with in your embedded iframe's src URL.

Create the Account

If you want to integrate OpenID using the RPX Provider, you must register the
application in the Provider website.

Goto: Create New Application Get Started Enter the Application Name like SocNet

And Domain name is the Token URL Domain name, it’s like local host or ip address.

Once you created the Application the provider will be given the apiKey and you click on
the Token URL Domain name it will go into our newly created application page, from
that page we need to given the policy url like http://localhost:8080/projectname/jsp
page name.

Your token_url

When configuring the sign-in interface, you supply a token_url parameter. This is where
the user will POST their token after completing the authentication process. You must
extract the token and pass into the auth_info API call.

Parameter Type                 Description
token     string               The token used for the auth_info API call

If the user cancels the OpenID sign-in transaction, they will make a POST to your
token_url without the token parameter.

Note: You can pass state through the RPX authentication transaction by adding query
parameters to your token_url.


The auth_info call is used in your token_url code, and is called after extracting the
token. Use the auth_info call to get information about the user currently signing in to
your web application.
auth_info – Request

API URL is        ApiKey=once      you      create     the
application&token=run the jsp page it created the token.

For the Above url we can get the user’s profile. Suppose one user logged in the gmail
account, the profile response is JSON and XML format.

User profile is

"profile": {
"displayName": "Valarmathi",
"preferredUsername": " Valarmathi ",
"url": "http:\/\/\/",
"providerName": "Other",
"identifier": "http:\/\/\/"
"stat": "ok"

And the XML format is like

<? Xml version='1.0' encoding='UTF-8'?>
<rsp stat='ok'>
Parameter Required? Description
apiKey    yes       Your RPX API key
token     yes       The token parameter received at your "token_url”.

                      'True' or 'false'(default). Return the extended Simple Registration
extended no           and HCard data in addition to the normalized Portable Contacts


Mappings can help you add OpenID sign-in to your existing user accounts without
changing your database schema. You probably have a "users" or "accounts" table in
your database. The mapping API lets you associate the primary key of an existing user
with an OpenID, and store that mapping on the RPX server. When a mapping exists for a
user, RPX returns both the primary key for the user and the associated OpenID in the
auth_info call. You then use the primary key to figure out which account to sign the user
into on your site.

New mappings are created with the map API call. Before using the map API call to save a
primary key to identifier mapping, you must first know who the user is on your site, and
have a record for them in your users or accounts table. This means that the user is
either already logged in with a legacy account, or they have been verified using RPX or
you have created a new record for them in the database but haven't yet stored that
mapping anywhere. Either way, new mappings are generally created right after a user
has verified their identity with RPX and you have extracted their identifier via the
auth_info API call.

The image below represents a website using RPX with a Users table that has a primary
key called "id". A user has bound three different OpenIDs to his account, and because
the website is using the mapping API he may use any one of his mapped accounts to
sign in as the Valarmathi user.
                                                        Mappings on RPX Server
                                               PrimaryKey             Identifier
      Your Users Table                             17
     Username        ID
     Valarmathi     17                             17
         …           …                             …                      …

After the mapping is made, when the user signs in with his OpenID, an auth_info response including the
primaryKey will be returned. Use the value of the primaryKey field to sign the user in as

    "profile": {
     "identifier": "http:\/\/\/",
     "primaryKey": "17"
    "stat": "ok"


Map an OpenID to a primary key. Future logins by this owner of this OpenID will return
the mapped primaryKey in the auth_info API response, which you may use to sign the
user in.

The map call is usually made right after a call to auth_info, when you already know who
the user is because they are signed in to your website with their legacy (or existing)

Map - Request
API URL is like apiKey= RPX API key& identifier= identifier returned
from the auth_info API call& primaryKey= primary key from your users table, as a string

Parameter       Required? Description
apiKey          yes         Your RPX API key
identifier yes            The identifier returned from the auth_info API call.
primaryKey yes            The primary key from your users table, as a string.
                          'true'(default) or 'false'. If 'false', only create the mapping if
overwrite    no
                          one does not already exist for the specified identifier.

Map - Response

This method has no specific response - It returns an empty success response if it
completes without error.

JSON Response
  “stat”: “ok”
XML Response
<? Xml version='1.0' encoding='UTF-8'?>
<rsp stat='ok'/>

Integration with OpenID in SocNet Site:

OpenID is integrated into the SocNet site for Login page. We need to create the new
table named as openid.

Openid table fields are

username as string
user_id is int
identifier is text

If the username is already exists, don’t want to store it. Otherwise we need to store it in
the database.

To top