User Centric Authentication using WSO2 Identity Solution

WSO2 Identity Solution provides a set of components to enable CardSpace/OpenID authentication on various platforms.

This 3-hour course is designed to provide an understanding of CardSpace/OpenID authentication protocols and how to use Identity Solution components.

The course covers following contents and now open for registration.

- Introduction to Microsoft CardSpace concepts

- Introduction to OpenID

- Enabling a CardSpace/OpenID authentication on sample J2EE web application using WSO2 Identity Solution Java relying party component

- Setting up the Identity Provider with LDAP connecting to an Active Directory

- Setting up the Identity Provider with a custom database with user account details

- Federated Identities with WSO2 Identity Solution

- Using custom claims to enable authorization in web applications

Federated Identities with Information Cards

This post explains how you could easily build an Identity Federation to enable Cross Company Authentication[CCA] with InfoCards.

Federated Identity is a mechanism which allows authentication across different enterprises in different trust domains - based on a trust factor.

I'll be using WSO2 Identity Solution to demonstrate how this could be achieved.

WSO2 Identity Solution, can be used as an Identity Provider to issue InfoCards - at the same time it comes with a set of relying party[RP] components to facilitate InfoCard based logins.

Let me explain the use case, first.

Employees of the 'Company A' need access to services hosted in 'Company B' and 'Company C'.

Both companies willing to share service access with 'Company A' - but, employees from 'Company A' should authenticate first and should prove that they are from 'Company A'.

The straight forward solution is to share 'Company A's' user store with the others.

But, this is not an extensible solution - when employees join and leave from 'Company A'.

This is where the Information Cards based solution fits in with WSO2 Identity Solution.

In this demonstration, I assume that the user store in 'Company A' is based on Active Directory [AD].

So, to start with, let's deploy WSO2 Identity Solution over 'Company A's' AD.

All the steps you need to know there are explained here in my previous blog post.

Please follow the exact steps given there and I'll be using the same names introduced in that post.

Once done with it - the user 'prabath' from 'Company A', could login to the WSO2 Identity Solution and download an Information Card, against his AD credentials.

Lets move to the next step - that is to 'Company B'.

'Company B' can use the Information Cards relying party components ship with WSO2 Identity Solution to protect their web applications.

First - you need to secure your Tomcat application server.

Please follow the exact steps given here - I'll be using the same names here - which were introduced there.

You can download the sample application for the 'Company B' from here.

Once downloaded copy all the jars inside 'endorsed' folder to [CATALINA_HOME]\common\endorsed and copy the 'javarp' folder to [CATALINA_HOME]\webapps.

I have already added the certificate of the WSO2 Identity Solution[hosted on localhost] to wso2is.jks - you can find inside 'javarp' folder - so, the 'Company C' is now ready to accept Information Cards from 'Company A' users.

Still - there is one step missing.

'Company A' - also should trust 'Company B' [as well as 'Company C'] to issue Information Cards to those.

This is how you do this.

In the machine you run the WSO2 Identity Solution you need to add the certificate of the CA who signed the 'Company B's' certificate to the [JAVA_HOME]\jre\lib\security\cacerts keystore. [here the default password is 'changeit'].

In our case, we used a self-signed certificate for the 'Company B' - so it's the same as 'Company B's' certificate.

You can save the certificate through the browser - by hitting the url, https://webapp:8443/javarp and following the appropriates steps.

Or you can simply export it from the keystore.jks.

:\>keytool import -alias webapp -file webapp.cer -keystore [JAVA_HOME]\jre\lib\security\cacerts

Next step is to tell the WSO2 Identity Solution, that you trust 'Company B'.

Here the admin can set 'Company B' as a trusted relying party by uploading it's certificate.

Go to https://localhost:12443/admin - login with admin/admin - select 'Trusted Relying Parties' and add the certificate.

All set - now the user 'prabath' from 'Company A' can visit 'Company B', say https://webapp:8443/javarp and login with his Information Card issued by 'Company A'.

Detecting Information Card Support

Following javascript will help you to detect Information Card support of a given browser and display Information Card based logins accordingly.

function isSupported()
{

  var ieversion = -1;

  if (navigator.appName == 'Microsoft Internet Explorer' ) {

    if (new RegExp("MSIE ([0-9]{1,}[\.0-9]{0,})").exec(navigator.userAgent) != null) {

      ieversion = parseFloat(regExp.$1);

      if (ieversion >= 7) {

        var embed = document.createElement("object");
        embed.setAttribute("type","application/x-informationCard");
        return ("" + embed.issuerPolicy != "undefined" && embed.isInstalled);

      }

      if (ieversion < 0 && navigator.mimeTypes && navigator.mimeTypes.length) {

        var handler = navigator.mimeTypes['application/x-informationCard'];

        if (handler && handler.enabledPlugin)
        return true;

        if (document.addEventListener) {

          var event = document.createEvent("Events");
          event.initEvent("IdentitySelectorAvailable",true,true);
          top.dispatchEvent(event);

          if (top.IdentitySelectorAvailable == true) return true;

        }

      }

    return false; 

    }     

  }

}

Information card support for IE 7+ is added using a browser add-on. To test the above script with IE 7+.

Personal Information Cards Under the Hood

Personal Information Cards provide a way where you can use them to register yourself with a web site and further use it to authenticate yourself.

This eliminates the burden of typing all your personal information each and every time you register with a new web site.

Once you have a personal information cards with the required claim values, the same card can be used at different websites for the purpose of registration and authentication.

This raises a question...

How come a given web site identifies you as a unique idenity based on your information card ?

Each and every information card has a non-editable claim value - known as Private Personal Identifier [PPID]. This is generated by the CardSpace it self.

For each personal information card you create, CardSpace generates a master key and a Card ID. Master key is 32 bytes of random data and Card ID is a GUID. This makes each card created unique from the rest of the cards.

PPID is not just unique for the information card it self.

It is a unique value for the Information Card + Relying Party combination.

PPID is generated with the CardID and with some properties from the RP certificate.

In case RP does not have a certificate, then it's the domain name from the site url is used along with the Card ID.

Apart from the PPID, CardSpace also creates a public/private key pair for the personal information card.

CardSapce uses the master key of the card along with some properties from the RP certificae to generate this public/private key pair.

Relying Party can retrieve the public key and the PPID from the Information card submitted to it and the user information can be stored against the PPID.

All the information sent with the card will be signed by the private key corresponding to that card.

So, once an RP gets a Card for authentication - it can verify the uniqueness of the user with the PPID and check the integrity with the public key.

The PPID generated by the CardSpace is a Base64 encoded SHA1 hash. This looks something like;

2QLepiNor3AfYCJ2tN9m3IlNXKNA/iwpVV+FCU1ZhxQ=

That is never readable and to avoid that there is a way you can generate a much readable site-specific id from it.

Randall says, the OpenID initiative, a 'waste of energy'.

Randall Stross in his recent article to The New York Times, highlights some of the very valid issues against the use of passwords.

"I once felt ashamed about failing to follow best practices for password selection — but no more. Computer security experts say that choosing hard-to-guess passwords ultimately brings little security protection. Passwords won’t keep us safe from identity theft, no matter how clever we are in choosing them."

Best practices on selecting better passwords always only provide guidelines for how to select a password which is 'hard to guess' - NOT unbreakable. With this point, I totally agree with Randall - Yes, true - passwords do not seem to be the 'right' solution for digital identity.

He further adds.

"As users, we would replace passwords with so-called information cards, icons on our screen that we select with a click to log on to a Web site. The click starts a handshake between machines that relies on hard-to-crack cryptographic code."

Yes, true - information cards provide a cryptographic solution to the authentication problem in a phishing resistant manner.

Even in this case - passwords are not totally taken out of the picture.

A given information card can be backed by a username/password, a self-issued information card or an X.509 token.

Also, in all three cases - if your machine, where you have installed all your Information cards, is protected by username/password - still we have not totally eliminated the risk of using passwords. Anybody who steals your machine username/password can easily use any of your information cards to authenticate in to any of the relying party web sites who accept your information cards.

Here comes the most interesting part of Randall's article.

"We won’t make much progress on information cards in the near future, however, because of wasted energy and attention devoted to a large distraction, the OpenID initiative. OpenID promotes “Single Sign-On”: with it, logging on to one OpenID Web site with one password will grant entrance during that session to all Web sites that accept OpenID credentials."

Oops... I am sorry... I totally disagree.

First I disagree with him on the point about Information cards.

CardSpace has made a good progress in the past and it will definitely in the future. It's not just Microsoft that has taken the CardSpace initiative forward - but it has also attracted many open source vendors as well. For example, WSO2 with it's Identity Solution has support for CardSpace - both as an Identity Provider as well as providing relying party components.

Second - I totally disagree with him on his comments on OpenID.

"...however, because of wasted energy and attention devoted to a large distraction, the OpenID initiative."

When such a comment is made - there needs to be enough facts to elaborate more on it. But, unfortunately there is nothing in it to justify.

Both OpenID and CardSpace are two technologies which support user-centric identity.

When you say - 'OpenID vs CardSpace' - it's simply an invalid statement. It should be 'OpenID and CardSpace'. Both the technologies work together smoothly. Please read this blog post by Kim Cameron.

"...OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else’s Web site."

This is totally misleading.

OpenID specifications never promote a single way of authenticating users to the OpenID Provider.

It can be username/password ,X.509 certificates or even Information cards.

I can take out many examples from the the web which support many of these authentication mechanisms for user authentication.

Randall, further adds.

"...Because the companies see the many ways that the password-based log-on process, handled elsewhere, could be compromised."

Once again - it seems Randall has misunderstood OpenID as a way of password-based login - sorry, sir - it is not.

Deploying WSO2 Identity Solution in production with custom certificates

WSO2 Identity Solution comes with a certificate for the 'localhost' signed by a sample CA.

In a production environment you need to setup your own certificate to work with the WSO2 Identity Solution and this post explains how to do it.

These are the steps you need to do.

1. Create a private/public key pair for your server [say, identity-provider]
2. Create a sample CA
3. Get your public key signed by your CA
4. Download and install WSO2 Identity Solution
5. Configure Identity Solution to use your certificate for identity-provider

In this case, we'll be creating the certificate for the host name 'identity-provider' - to test this scenario as it is, please add the following entry to the C:\windows\system32\drivers\etc\hosts file.

127.0.0.1 identity-provider

We use OpenSSL to build the required CA infrastructure. For Windows you can download Win32 OpenSSL v0.9.8g from here.Once installed make sure you add C:\OpenSSL\bin [i.e [INSTALLED_LOCATION]\bin] to the PATH env variable.

Create a folder "keystore" locally and inside that folder create two sub folders, "CA" and "IS".

From the "keystore" folder,

:\> cd IS

Creating private/public key pair for the server.

:\> keytool -genkey -alias identity-provider -keyalg RSA -sigalg MD5withRSA -keysize 1024 -dname "CN=identity-provider,L=SL,S=WS,C=LK" -keypass wso2is -keystore wso2is.jks -storepass wso2is

Creating a certificate signing request.

:\> keytool -certreq -v -alias identity-provider -file ../CA/csr.pem -keypass wso2is -storepass wso2is -keystore wso2is.jks

Building the CA infrastructure.

:\> cd ../CA

Creating CA public/private key pair - you need to give a password when requested.

:\> openssl req -x509 -newkey rsa:1024 -md5 -keyout wso2cakey.pem -out wso2cacert.crt

Signing the server certificate.

:\> openssl x509 -req -days 365 -md5 -in csr.pem -CA wso2cacert.crt -CAkey wso2cakey.pem -CAcreateserial -out ../IS/iscert.crt

:\> cd ../IS

Importing CA public certificate to the server keystore.

:\> keytool -import -alias wso2ca -file ../CA/wso2cacert.crt -keystore wso2is.jks -storepass wso2is

Importing the signed server certificate to the server keystore.

:\> keytool -import -alias identity-provider -file iscert.crt -keystore wso2is.jks -storepass wso2is -keypass wso2is

At the end of this process, you'll end up with a keystore, wso2is.jks at [keystore]\IS. The password we provided for this keystore and it's private key is wso2is.

Now let's download the WSO2 Identity Solution from here and unzip it to a local location.

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 copy [keystore]\IS\wso2is.jks to [IS_UNZIPPED_LOCATION]\conf and replace the existing one.

Open the file [IS_UNZIPPED_LOCATION]\conf\server.xml and do a find for 'localhost' and do a replace all with 'identity-provider'.

That's all you need to do - to get this working.

Anyway following section in the same file is useful to have a look.

<KeyStore>
  <!-- Keystore file location-->
  <Location>${wso2wsas.home}/conf/wso2is.jks</Location>
  <!-- Keystore type (JKS/PKCS12 etc.)-->
  <Type>JKS</Type>
  <!-- Keystore password-->
  <Password>wso2is</Password>
  <!-- Private Key alias-->
  <KeyAlias>identity-provider</KeyAlias>
  <!-- Private Key password-->
  <KeyPassword>wso2is</KeyPassword>
</KeyStore>

Now, you can start the server with [IS_UNZIPPED_LOCATION]\bin\wso2is.bat.

Just type https://identity-provider:12443 to access the Identity Provider home page.

You may see browser indicating a warning here - that is because our CA is not trusted by the browser. To avoid that you can simply add our CA cert to the trusted CA certificate store.

Deploying WSO2 Identity Solution over an existing MySQL user store

WSO2 Identity Solution can be used as an Information Card provider as well as an OpenID Provider.

This post explains how you can customize WSO2 Identity Solution to expose an existing user base residing on a MySQL database - and facilitate them with Information Cards and OpenID logins.

Let me further explain this scenario.

You have a set of users with a set of attributes defined for each.

Now the requirement is your company wants you to assign each of your users an OpenID and also run an OpenID Provider your self - and you need to do minimal changes to the existing system.

I'll explain everything you need to know here in a step-by-step manner.

Setting up the existing environment

- Download WampServer 2.0 from here and install it locally.

- Start the wampserver and run MySQL service.

- Add [WAMP_INSTALLED_LOCATION]\bin\mysql\mysql5.0.51b\bin to the PATH env variable.


:\>mysqladmin -u root password mysql

:\> mysql -u root -p

[type your password : mysql]

mysql> CREATE DATABASE COMPANY_DB;

mysql>USE COMPANY_DB;

mysql>CREATE TABLE `users` (`uid` varchar(60) NOT NULL,`name` varchar(60) NOT NULL,`pass` varchar(32) NOT NULL,`mail` varchar(64) ,`openid` varchar(60) NOT NULL, `firstName` varchar(60) NOT NULL,`lastName` varchar(60) NOT NULL,PRIMARY KEY (`uid`));

mysql>INSERT INTO users VALUES ('prabath','prabath','prabath','prabath@wso2.org','http://localhost:12080/user/prabath','prabath','siriwardena');

mysql>COMMIT;

Now we are done with setting up the existing environment.

You may have already noticed that for my convenience I created the 'users' table with an 'openid' column - which you may not have in your existing 'users' table. In that case you need to alter the table 'users', add the new column 'openid' and populate that column with values derived from the 'uid' column - which will create unique OpenIDs for all your users.

Building & deploying WSO2 Identity Solution from source

- Download the latest code from the SVN repo: https://svn.wso2.org/repos/wso2/trunk/solutions/identity

- Then, from the root directory (say [Identity] ) of the downloaded code.

[Make sure you have installed Maven2]

:\> mvn -Drelease clean install

-The above will create a zip file distribution at [Identity]\modules\distribution\target.

- Unzip the Zip file to a local folder.

- Download MySQL JDBC driver from here and copy the mysql-connector-java-5.1.6-bin.jar to [IS_INSTALLED_DIR]\lib

- 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.

- Start WSO2 Identity Solution with [IS_INSTALLED_DIR]\bin\wso2is.bat

Configuring WSO2 Identity Solution to use MySQL user store

- Go to url : https://localhost:12443/admin and login with admin/admin [user/password] - then select 'User Stores'

- Click 'sampleRealm' link [Here we are using the JDBCRealm to connect to the MySQL database].

- Click 'Edit'

- Set the following properties appropriately and update.

UserCredentialColumn : pass
ConnectionPassword : mysql
ConnectionUserName : root
ColumnNames : mail,openid,firstName,lastName
DriverName : com.mysql.jdbc.Driver
UserNameColumn : uid
ConnectionURL : jdbc:mysql://localhost/COMPANY_DB
UserTable : users

- Click 'Set as Default' against 'sampleRealm'.

- Click on 'Define Claims' and select 'Given name','Surname' & 'Email address' [Dont uncheck any claims which are already selected]

- Click on 'Claim Mappings'.

- Click on 'Given name','Surname','Email address' and 'OpenID', and do the claim mapping appropriately.

- Once done the claim mapping it should look like the following.

- Try login to Identity Solution with your credentials available in MySQL database [ in our case prabath/prabath] - go to the url : https://localhost:12443

- To test your OpenID [http://localhost:12080/user/prabath], Signout first and from the Home page [https://localhost:12443], Click on OpenID and then type your OpenID.

You can find more documentation on WSO2 Identity Solution from here.

CardSpace private desktop

Windows desktops provide isolation from code running on other desktops.

Once you login to Windows, what you see is the default desktop - where users run their applications.

Lets start with the most familiar private desktop you see on a Windows environment.

Just press Ctrl+Alt+Del - here comes the 'winlogon' desktop, which is a private desktop, isolated from the applications running on the default desktop.

By switching to the winlogon private desktop - it makes more difficult for malicious applications running on the default desktop to steal sensitive information.

Now, lets go back to the subject.

Once the CardSpace pops up for card selection - it also creates a private desktop.

It looks like your machine is frozen and even the windows clock seems to be not running.

Actually - what you see here behind the Identity Selector is an image taken of your default desktop at the time the Identity Selector being invoked and this image being set as the background image of the CardSpace private desktop.

As per the reasons mentioned above, we get following benefits by running Identity Selector in a private desktop.

1. Protection for users when they enter confidential data while using Managed Information Cards.

2. Malicious applications running on the default desktop cannot access the Identity Selector to capture information regarding user's card usage.

Not all the time CardSpace runs on a private desktop.

In some cases, CardSpace UI also runs on the default desktop.

Say for example, once the CardSpace pops up, click the link 'Restore Cards' and then the 'Browse' button.

This action will switch the user from CardSpace private desktop to the default desktop.

But, even in this case the user won't feel that he's moving away from the private desktop - here this is a trick used to give the user a consistent experience by setting a 'faded desktop' image in the background.

Private desktops in most of the cases will protect you from malicious applications, but still you are well exposed to hardware based attacks such as external keyllogers which could intercept your keystrokes.

WSO2 Beefs Up SOA Identity Solution

Read the complete article on ebizQ...

Microsoft releases "Zermatt" Developer Framework for claims-based identity

Microsoft very recently released "Zermatt" Developer Framework for claims-based identity.

Zermatt is a set of .NET Framework classes; it is a framework for implementing claims-based identity in your applications. This can be used in any web application or web service that uses the .NET Framework version 3.5.

Zermatt helps building externalized authentication capabilities for "relying party" applications and build custom "identity providers" (STS).

Zermatt beta is avaialble to download from here.

Zermatt also requires .Net 3.5 to be installed. It has been verified on Windows 2K3 SP2 with IIS 6.0 and Windows Vista SP1 and Windows Server 2008 with IIS 7.0.

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 http://wso2.org/downloads/solutions/identity.

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
Apache2
-Easy integration interface for developers
-Support for content management frameworks such as Drupal,
MediaWiki
-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

Identity Interop begins....!

Most of the participant of RSA 2008 have hosted their end points by now.

We have hosted our WSO2 Identity Solution at https://is.test.wso2.org.

WSO2 acts as both an Information Card provider with SAML 2.0 support and an OpenID Provider.

Once you visit the above url you can register yourself either with a self-issued information card [password-less login] or by providing user name/password. Once you are are a registered user, you are automatically assigned an OpenID - which can be used at any OpenID RP. Also, once you logged-in you can download an OpenID Information card corresponding to your default profile.

WSO2 relying party end point is available at https://is.test.wso2.org/javarp.

Why OpenID leads to CardSpace...

Kim Cameron writes here...

CardSpace Authentication Using WSO2 Identity Solution

WSO2 Identity Solution provides a set of components to enable CardSpace authentication on various platforms. This 3-hour course is designed to provide an understanding of CardSpace authentication protocols and how to use Identity Solution components.

Following objectives will be covered during the training.

1. Understand CardSpace authentication basics
2. Learn how to use WSO2 Identity Solution's relying party components to enable CardSpace authentication on a web application and to be able to issue custom managed tokens using the Identity Provider.

You can register for the training from here and will be conducted on 31st Jan 2008, from 9.00 am - 12.00 noon (PST). Hurry up to secure your place...!

Mooshup goes LIVE!

Mooshup.com, a community of mashup authors, where they can develop, share, discover, and run Javascript-powered mashups, launched couple of hours ago.

Mooshup.com, powered by WSO2 Identity Solution, uses InfoCards to signup/signin.

Have a GO!

WS-Trust - Under the Hood

Available on Channel9.

PIN protect your Personal Infocard

Many RPs offer passwordless login with Personal Infocards.

But, what if you share your Windows login - this is the case where you need to protect your Infocard with a PIN.

CardSapce supports you to PIN protect your Infocard.

Windows registry settings for Microsoft CardSpace

Follwong are some of the windows registry setting, corresponding to Microsoft Identity Selector.

1. HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/x-informationCard

Internet Explorer 7.0 supports information cards using a MIME handler extension called Microsoft Information Card IE Helper, available from icardie.dll. The above registry key links the MIME type for information cards to the handler.

2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\InformationCard Token Provider

The handler is responsible for calling the Identity Selector, passing parameters specified by the object tag or XHTML binary behavior. For Internet Explorer 7.0, the identity selector defaults to Windows CardSpace, indicated by the above registry entry.

3. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Default Behaviors\INFORMATIONCARD

For the object tag syntax, the MIME handler is triggered through the InformationCardSigninHelper Class, enabled by default in the Internet Explorer 7.0 add-ons.If this add-on is disabled, the object tag will not trigger identity selection, but this setting has no effect on XHTML syntax. The XHTML information card behavior is configured in a string entry labeled INFORMATIONCARD under the registry key.

The object tag uses the MIME type application/x-informationCard:

<object id="informationCard" name="informationCard" 
        type="application/x-informationCard">
    ...
<object>

The information card binary behavior can be specified in XHTML by using a #default#informationCard behavior in the <informationCard> element:

<ic:informationCard name="xmlToken" 
      style="behavior:url(#default#informationCard)" ... >
      ...
</ic:informationCard>

Infocards Vs OpenID Infocards

In this post, I'll be discussing the modifications required for the Microsoft's identity metasystem, to support OpenID Infocards. Identity metasystem consists of three parts. Identity Provider, Relying Party and the Identity Selector. Let's take one by one.

First, it would be better to identify the protocol flow under the OpenID Infocard scenario.

1.User acquires an OpenID Infocard from an OpenID Infocard enabled Identity Provider and installs it in his Identity Selector.

2.User browses to an OpenID Relying Party [RP]

3.User invokes an element on the page to send an OpenID token to the Relying Party. In this case user will be clicking on an image, just like the following – which says this RP accepts OpenID Infocards. [ Same as 'We accept American Express' in your nearest shopping mall]

4.Identity Selector detects the "application/x-informationCard" OBJECT element on the RP's login page, requesting an OpenID token. This is same as in the normal Infocard scenario. Basically type="application/x-informationCard" indicates to the browser that it has to invoke the underlying Identity Selector and passes the associated attributes to the Identity Selector. In the case of an OpenID Infocard we set the value of the parameter “tokenType” to “http://specs.openid.net/auth/2.0”

5. User selects an OpenID Information Card to use. In this case Identity Selector only presents the Inforcards which are of 'tokentype', “http://specs.openid.net/auth/2.0” for user selection.

6.Identity Selector sends a Request Security Token (RST) to the Security Token Service (STS) endpoint of the Identoty Provider that issued the card.

7.Identity Provider issues an OpenID Authentication Response, encodes that response in an OpenID token, and encapsulates the token in a Request Security Token Response (RSTR).

8.Identity Provider returns the RSTR to the Identity Selector.

9.Identity Selector POSTs the response back to the RP.

10.RP extracts the OpenID Authentication response from the OpenID token and returns to the normal OpenID verification flow.

Basically, in most of the cases the steps are exactly same as in a normal Infocard case. Only difference is, in each case we have to handle the OpenID token [instead of SAML token], as well as we also need to support OpenID Identifier claim type [http://schema.openid.net/2007/05/claims/identifier].

So, both the Identity Provider, as well as the Relying Party need to be able to identify and handle OpenID tokens, while the Identity Selector's behaviour is unchanged, since the tokens are opaque to Identity Selectors.

OpenID with Cardspace

I assume you've already heard about Windows Cardspace, which comes with .NET Framework 3.0. If not, following are few good references which you could go through.

1. MSDN Webcast: Windows CardSpace (Level 200)
2. MSDN Webcast: Exploring Windows CardSpace
3. MSDN Webcast: Introduction to Windows CardSpace

So, we are back to the subject, what OpenID has to do with Cardspace? Cardspace [Infocards] removes the issue of phishing attacks - while OpenID not. [but, still there are few ways you can make OpenIDs not susceptible to phishing attacks - one such way is the SeatBelt addon for FireFox].With OpenID, at the relying party,when you type your OpenID, you are redirected to the OpenID Provider site for authentication and again redirected back to the original site [the relying party]. With OpenID Infocard, we remove this redirection step. At the same time - we loose the SSO [Single Sign-on] capability, which is normally available with OpenID, but not with Infocards.

So - get ready for a demonstration.

1. Go to https://openidcards.sxip.com/TokenService/CreateProfile.html, and create a profile for you - just a user name and a password.

2. Go to https://openidcards.sxip.com/TokenService/GenerateCardByUsername.html [openID Infocard Provider], enter Card Name, User Name and Password - which you created in Step 1, then Click to download the OpenID Infocard.

3. Make sure you have .NET 3.0 and IE 7 installed. Just click on the downloaded file and install it in the Windows Cardspace.

4. Now go to the relying party site - https://openidcards.sxip.com/demorp/, Click on the image to login with your OpenID Infocard.

5. Now the Identity Selector will pop-up - so you can select the Infocard, that you installed - select it and 'Send' - enter your password.

6. Now you are done and on the required page, with no redirections.

This is a simple and very basic demonstration - and it hides your OpenID till you finally logged in.

At WSO2,we have the WSO2 Identity Solution - which enables LAMP and Java websites to provide strong authentication based on the new interoperable Microsoft CardSpace technology. Right now we are also working on integrating OpenID support for WSO2 IS.