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.

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.