Wednesday, April 30, 2008

Improve your Google PageRank with OpenID

Under Google PageRank, the importance of a page is judged by the number of pages linking to it as well as their importance.

Higher the citations to your web site from the rest - higher the PageRank.

Turn your blog(web site) to your OpenID - my previous post explains how to do that - and start commenting on other sites with your OpenID - which automatically links back to your web site.

Friday, April 25, 2008

Yahoo Messenger: Catch who cheat you

Buddy Spy allows you to monitor and keep track of what other Yahoo Messenger! users are doing, even if they are in Invisible or Stealth Mode. The program shows if the user is online, what chat room they are in (if any) and if their web cam is online.

Thursday, April 24, 2008

BBC joins OpenID Foundation

Read the announcement here...

A company/organization joining OpenID foundation will have the following benefits and the annual membership fee varies from $100 to $10000.

-Use the OpenID Foundation Member logo on your company website, blog, and other marketing materials
-Display your corporate logo/name on the OpenID Foundation website and promotional materials
-Propose, lead, and participate in OpenID technical and marketing work groups
-Vote on ratification of OpenID specifications and recommendations
-Be eligible for inclusion in OpenID Foundation press releases and industry events
-Opportunity to meet, exchange views, collaborate with peer organizations in innovative, open source efforts

OpenID integration of WSO2 Identity Solution [Podcast]

In this podcast I talk to Oxygen Tank on the OpenID integration of WSO2 Identity Solution. The integration enhances the WSO2 Identity Solution to cater to a wider audience for Web based authentication. OpenID is a key feature in decentralizing single sign-on, much favored by many users. 

Tuesday, April 22, 2008

Social white-listing with OpenID

The post [1] hints about the concept of social white listing as a mechanism for avoiding spams and restricting access to a set of trusted users, in a much scalable manner.

This concept can be further extended with an OpenID Provider and OpenID relying party components. Let me suggest...

With this, OpenID Provider will enable it's users to maintain (a) white list(s) under their corresponding accounts.

A given white list contains a set of OpenIDs where the corresponding user trusts.

A white list entry also can be either an OpenID [] or a wild card entry [* --> I trust all the users from].

The user can add entries to the white list manually one by one or can be imported from a file [e.g: [2] shares a set of white-listed OpenIDs].

OpenID Provider defines an attribute under the OpenID Attribute Exchange to contain a white list of a given user [ - yet to propose].

OpenID relying party components will enable the support;

1. To maintain a white list at the RP end
2. Request users' white list at the time they log in
3. Share the white list with the rest.


1. User registers him self with an OpenID Provider. [user gets an OpenID]
2. User logs into the OpenID Provider and populates his white list.
3. User visits RP web site and types his OpenID for login.
4. RP finds the given user is in it's white list [initially the RP admin will populate it's white list with a set of trusted users]
5. User will be redirected to the OpenID Provider for the authentication + request to his white list
6. At OpenID Provider user authenticates successfully and approves the request for the white list
7. User logs into the RP successfully and RP updates it's white list



Why OpenID?

Let's start with the formal definition.

"OpenID is a url, which facilitates, decentralized single sign-on".

"decentralized" - does not sound right..., let me explain what it really means.

"Decentralized" means - it's not centralized - in other words it does not have a central server controlling everything. Comparing this with Microsoft Passport is the best way to understand. Under Microsoft Passport there is a central server controlling everything and facilitates single sign-on. But, under OpenID there is no such central server - as per your wish, if you want, you can run your own OpenID Provider.

Second point, how OpenID facilitates SSO.

With SSO, you logs in once with your credentials - and there after you access different relying party web sites without the need to relogin to the OpenID Provider. Each relying party will redirect you to the OpenID Provider for authentication. OpenID Provider will give the user the option to let the OpenID Provider remember his credentials - this avoids the user, the need to relogin there after. If user accepts this option - he only needs to present his credentials only once to the OpenID Provider upon his first redirect to the OpenID Provider. With this, for the rest of the relying party web sites, the user does not need to relogin to the OpenID Provider.

This is not the only benefit of using OpenID.

With OpenID, you need not to maintain different set of profiles at different relying party web sites - as well as seperate user names and passwords. Once you maintain a single profile at your OpenID Provider, you can simply share it with the rest.

Another key benefit is, you never loose your favourite user name, with OpenID.

In the context of OpenID - your user name is your OpenID - it's not necessarily need to be an URL derived from your user name, you use to login to your OpenID Provider.

For example, first I sign up with with the user name 'prabath' - and I get my OpenID as So... my user name to OpenID relying party web sites, is - not just 'prabath' - 'prabath' is only the user name that I use to login to the OpenID Provider. is assigned to me by my OpenID Provider - but... What if it's not my favorite user name - in other words what if it's not my favorite OpenID ??? I may not want to use the OpenID given to me by my OpenID Provider... I have a blog and I need to use my blog url as my OpenID. And that is my favorite OpenID or in other words, that is my favorite user name for other OpenID relying party web sites.

This can be easily done with OpenID - you simply need to add a tag to your blog - which will delegate OpenID authentication functionality to your OpenID Provider - so, with this you can maintain your profile at any OpenID Provider - but still you can select an OpenID as per your wish - but keep in mind, it should be an url, which you own... otherwise there is no way you can add the 'delegate' tag to delegate the OpenID authentication functionality to your OpenID Provider.

Another benefit of OpenID is, you never loose it. I guess this requires a better explanation.

If you maintain different accounts at different relying party web sites and what if you loose your password... or somebody else got hold of it. You loose it forever - no recovery at all if somebody else got hold of your password and changed it. If this is your Yahoo account or the Facebook - the damage is immense and your personality can be destroyed.

I can see a BIG question mark right on top of your nose :-). How come OpenID solves this?

With OpenID - you always use a url, which is totally under your control and you own the domain name. You can open an account with any OpenID Provider, but, still you can use your own url and delegate it to your OpenID Provider. So, what if - you loose your OpenID Provider password. Who ever stolen it will have access to all your relying party web sites - but the damage he can do is minimized and only till you realize you have lost your OpenID Provider password. You need not to worry about the lost password - you still own your OpenID url, simply open a new account with a OpenID Provider and change the delegate tag in your web page to point to the new account. That will make the lost password, useless.

Wednesday, April 16, 2008

Adding OpenID RP support made easy with WSO2 Identity Solution

WSO2 Identity Solution, released last week, includes OpenID relying party components to add OpenID support to your web site.

OpenID it self, has a huge audience which cannot be easily ignored by any relying party web site.

Following two guides explain in detail, all you need to know to add OpenID relying party support and get it running...

1. Relying Party Developer Guide - II - Describes how to enable OpenID with Simple Registration and OpenID InfoCard login for websites.

2. Relying Party Developer Guide - III - Describes how to enable OpenID login with OpenID Attribute Exchange and OpenID Provider Authentication Policy Extension for websites.

If you have any questions, please join the identity-dev mailing list by sending a mail to and post your questions there.

Monday, April 14, 2008

SourceForge hints adding OpenID Relying Party support

Luke Crouch, a SourceForge’s developer, hints here adding OpenID Relying Party support for SourceForge.

Saturday, April 12, 2008

Passwordless login with WSO2 OpenID Provider

There are two patterns found, adapted by many sites to implement passwordless login.

1. Signup directly with your Personal Information card.

2. Signup with a username/password based account and associate any number of Personal Infocards with it. So - later you can have passwordless login with any of the associated Infocards. Also - with this approach if you lose your Infocard you need not to worry too much, you have the other option - username/password login.

WSO2 OpenID Provider supports both of these and available to download from here.

Once downloaded, follow the OpenID Provider Administrator's Guide, which explains all you need to know to setup the OpenID Provider, locally.

You also need to download Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 5.0 from here and copy the two jar files from the extracted jce directory (local_policy.jar and US_export_policy.jar) to $JAVA_HOME/jre/lib/security.

Now, either you can signup with a self-issued information card or register with a username/password combination and later associate a self-issued card with your account.

The sample application associated with the relase can be used to test your passwordless login - simply hit https://localhost:12443/javarp

Tuesday, April 8, 2008

WSO2 OpenID Provider Guide for Users

WSO2 released it's Identity Solution v1.5 yesterday, which is available for download from here.

This guide includes all you need to know about it from a user's perspective.

The same release being deployed at for the purpose of RSA Interop tetsing - which also demonstrates the functionality of WSO2 OpenID Provider.

WSO2 OpenID Provider interoperates with Blogger and Yahoo OpenID.

Please note that your OpenID obtained from will not last long, since the server can be reset. Please use this as an demonstration and to work on interop testing.

WSO2 Identity Solution 1.5, feature-rich with OpenID

WSO2 announced the release of WSO2 Identity Solution 1.5 today.

The WSO2 Identity Solution enables LAMP and Java websites to provide strong authentication based on the new interoperable Microsoft CardSpace technology, released version 1.5 today.

This new release includes OpenID and OpenID Information Cards, further enhancing the WSO2 Identity Solution to cater to a wider audience for web based authentication. OpenID is a key feature in decentralizing single sign-on, much favored by many users.

The WSO2 Identity Solution also works with current enterprise identity directories, such as those based on the Lightweight Directory Access Protocol (LDAP) and Microsoft Active Directory, allowing them to leverage their existing infrastructure. In addition to the Identity Provider the WSO2 Identity Solution provides a Relying Party Component Set which plugs into the most common Web servers to add support for CardSpace authentication and now OpenID WSO2 Identity Solution 1.5 can be downloaded from

New features in version 1.5

* OpenID Provider and relying party component support
* OpenID information cards based on user name-token credential and self
issued credential
* SAML 2.0 support

Other Key Features

*Identity provider
-Simple management console
-Ability to connect to custom user stores (LDAP/Microsoft
ActiveDirectory, JDBC)
-Built in user store
-Support for the CardSpace default claim set
-Support for custom claim dialects and claims types
-Statistics/reporting/audit trail
-Ability to revoke information cards
-Issues information cards based on username-token credential and self issued credential

*Apache HTTPD relying party module - mod_cspace
-CardSpace authentication support for static web content
-Support for any server side scripting language supported by
-Easy integration interface for developers
-Support for content management frameworks such as Drupal,
-Java Servlet Filter relying party component
-Provides an intuitive plug-in for J2EE web application developers to enable CardSpace authentication
-Supports multi-valued claims
-Supports a set of simple operation modes