Mooshup: The yougest member of the OpenID family

WSO2 Mashup team recently upgraded their community site, Mooshup, with the Mashup Server 1.5.1.

With this, Mooshup enbles OpenID login - in addition to the Information Card based login, which it had already supported.

Never they leave... just checking out...

Dr. Sanjiva, addressing the farewell party to Ruchith,Deepal,Saminda, Sanka, Sandakith, Dinesh, Diluka, Suran & Chandima - who left the company for higher studies, mentioned, "You can check-out WSO2 any time you like, But you can never leave!" - following the famous Hotel California.

I've been working closely with Ruchith during last year or so - in fact Ruchith is the one who interviewed me for WSO2.

To be honest, it's my privilege to work with such a talented person.

He's not just technically talented - but a great presenter, a patient teacher and a fantastic leader.

Ruchith has made him self famous in the open source community - specially in the web services security arena - and the WSO2 Identity Solution is a brain child of him - but he still finds time to answer any dumb question thrown to him.

I am still young to WSO2 to admire his service there - but any WSO2er will.



I recently had an opportunity to go on a business trip to UK/US with Ruchith and while we were in US we visited one of our clients there and on the way back to hotel - Ruchith mentioned that he truly feels guilty to leave WSO2 at this moment. He further added that - WSO2 has built him up during last few years from zero to hero - and at the time he's in a great shape to help back WSO2 - he has to leave - which he felt guilty about.

Also, once we were in London, due to extremely personal reasons - Ruchith had to say 'no' to a request came to him from the company to do a training on Axis2. It was a very valid reason - and he had no other option. Later, from my colleagues at WSO2, I learnt that this was the first time Ruchith has said 'no' for such a request - it was clearly reflected on his face just after conveying his decision back to the company - and I have never seen Ruchith being so upset, before.

Once again, I am still young to WSO2 to comment on his loyalty - but, any WSO2er will.

That is... just one side of the story - let me add few words on the other side as well.

There was a time Ruchith felt he should postpone his admission to grad school by either a semester or by an year.

Any company CEO will definitely admire this decision and probably put a party on this.

But, Dr.Sanjiva, knowing very well the value Ruchith can add to WSO2 - encouraged him to leave the company to pursue his higher studies on time - which Ruchith finally had to agree.

This is fantastic - but not a surprise to anybody aware of WSO2 culture.

Ruchith: it's been great working with you for last few months and I wish you all the very best for all your higher studies - make your country and people proud of you...!!!

Complex Event Processing with Esper and WSO2 ESB

view presentation (tags: esbwso2esper)

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.

Mashup Server ready to ship with OpenID support

WSO2 Mashup Server latest release 1.5 is ready to ship on next Monday with OpenID support.

OpenID relying party support on Mashup Server is powered by WSO2 Identity Solution relying party components.

Further details on this new release available here.

OpenID with PAPE in plain English

This post discusses how PAPE works and demonstrates it's usage with WSO2 Identity Solution.

[You may also read this blog post by Nandana on "OpenID, Phishing & PAPE, Are we there yet? "]

Let me first explain what PAPE is.

PAPE stands for OpenID Provider Authentication Policy Extension - which is an extension to the OpenID Authentication.

An extension to OpenID Authentication is a protocol that "piggybacks" on the authentication request and response. Extensions are useful for providing extra information about an authentication request or response as well as providing extra information about the subject of the authentication response.

With PAPE, an OpenID Relying Party can add additional information into the OpenID Authentication request - such as;

1. preferred_auth_policies
2. max_auth_age

Let me explain what each one of them means.

With preferred_auth_policies, an RP can attach zero or more authentication policy URIs that the OP SHOULD conform to when authenticating the user. If multiple policies are requested, the OP SHOULD satisfy as many as it can.

Let me make this much clearer.

If RP wants it's users to be authenticated in a phishing resistant manner, then RP will attach the policy URI, http://schemas.openid.net/pape/policies/2007/06/phishing-resistant as the preferred_auth_policies.

If RP wants it's users to be authenticated in both a phishing resistant manner and a multi-factor way , then RP will attach the policy URIs, http://schemas.openid.net/pape/policies/2007/06/phishing-resistant and http://schemas.openid.net/pape/policies/2007/06/multi-factor as preferred_auth_policies.

One thing I want to emphasize here...

Given the fact that RP requested OP to do the user authentication in such a manner - does not mean OP will follow the exact authentication policy request.

In other words, an RP could request OP to authenticate it's users in a phishing resistant manner - but in case OP does not support phishing resistant authentication, then it will simply authenticate the user with the available method. But... OP will also let the RP know the method it used to authenticate the user. So - it becomes a decision up to the RP to decide whether to let user in or not.

Let's see how this works in a practical scenario.

We have hosted the WSO2 Identity Solution at https://is.test.wso2.org and the PAPE demonstration is available at https://is.test.wso2.org/javarp/.

Once you are at the demo site, find the section - "OpenID PAPE Demo" and type your Yahoo OpenID there.

Select "http://schemas.openid.net/pape/policies/2007/06/phishing-resistant" as your authentication policy.

In this case an OpenID RP sends a PAPE request to an OP which does not support PAPE [Yes, Yahoo still does not support PAPE].

This is what you get as the response.

Authentication Policies: none
NIST Auth Level: 0
Auth Age: -1

For the time being lets only focus on "Authentication Policies" - here Yahoo OP returns no policies. That is Yahoo has ignored the PAPE request by the RP. So, now RP can decide whether to let user in or not.

Let's try another example. This time we use an OpenID from WSO2 OpenID Provider. You can go there, register yourself and get an OpenID.

WSO2 OpenID Provider supports login with both the username/password and Information Card based logins.

First directly login to the OP and then register a self-issued Information Card with the OP. We'll be using this Information card later-on to login.

Once you are at the demo site, find the section - "OpenID PAPE Demo" and type your WSO2 OpenID [http://is.test.wso2.org/user/test] there.

Select "http://schemas.openid.net/pape/policies/2007/06/phishing-resistant" as your authentication policy.

In this case an OpenID RP sends a PAPE request to an OP which supports PAPE.

So, once you are redidirected to OP for authentication, login with your registered Information card.

You'll get the following as the PAPE reponse.

Authentication Policies: http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
NIST Auth Level: 1
Auth Age: -1

This indicates you've being authenticated in a phishing-resistant manner.

In no means, PAPE does not limit you to the following three authentication policies.

1. http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
2. http://schemas.openid.net/pape/policies/2007/06/multi-factor
3. http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical

Additional policies can be specified elsewhere and used between OPs and RPs.

For example, myOpenID defines the policy URI, http://janrain.com/pape/callverifid.html for it's CallVerifID. In this post I blogged about how CallVerifID works.

Hope, by now it's very much clearer how PAPE works.

There are few things I skipped during the discussion.

Let's go back to them.

In PAPE request, RP also can add the parameter "max_auth_age" as well.

This is an optional parameter in the PAPE request, where the RP may or may not request.

Once max_auth_age is set in the PAPE request, if the End User has not actively authenticated to the OP within that number of seconds [max_auth_age] specified in a manner fitting the requested policies, the OP SHOULD authenticate the End User for this request.

Let's go back to the PAPE response. I skipped explaining two parameters, NIST Auth Level and Auth Age.

If the RP's request included the "max_auth_age" parameter then the OP MUST include "auth_time" [Auth Age] in its response. If "max_auth_age" was not requested, the OP MAY choose to include "auth_time" in its response or just send "-1" as the value.

The NIST Auth Level is the the Assurance Level as defined by the National Institute of Standards and Technology (NIST) corresponding to the authentication method and policies employed by the OP when authenticating the End User.

This value varies from 0 to 4 (inclusive).

The following table provides examples of common authentication technologies and their mapping to NIST Assurance Levels.

Using WSO2 ESB with FIX - Supporting Financial Messaging

| View | Upload your own

WSO2 Beefs Up SOA Identity Solution

Read the complete article on ebizQ...

Building & Deploying mod_cspace on Windows

mod_cpace is an Apache HTTPD module for processing Information Card based logins, which can be used with any Web application that is hosted with Apache HTTPD.

This has a binary distribution for Ubuntu, but NOT for Windows.

This post explains all what you need to know how to build mod_cpace for Windows from the source.

I am using Visual Studio 2008 Express Edition to do the build and the IDE can be freely downloaded from here.

Also, make sure you have installed .NET Framework 3.5 in your machine as well as the IE 7.

First we need to download the latest code from the SVN repository. You may use TortoiseSVN client for this, which is freely available from here.

Downloal all the code from https://svn.wso2.org/repos/wso2/trunk/solutions/identity/modules/mod-cspace to your local repository [LOCAL_REPO].

Now share the folder [LOCAL_REPO]\build\win32\vc\lib and map the network drive 'W' to this shared folder.

Solution file [mod_cspace.sln] is available at [LOCAL_REPO]\build\win32\vc\apache2 and click the file to open with VS 2008 Express Edition.

Add the following to your PATH env variable.

W:\openssl\bin;W:\libxml2-2.6.30.win32\bin;W:\iconv-1.9.2.win32\bin;W:\zlib-1.2.3.win32\bin;W:\libxmlsec-1.2.11.win32\bin;W:\libxslt-1.1.22.win32\bin

Add the following to your CLASSPATH env variable.

W:\apache2.2\apr-1.lib;W:\libxml2-2.6.30.win32\libxml2.lib;W:\apache2.2\libhttpd.lib;W:\apache2.2\aprutil-1.lib;W:\apache2.2\libapr-1.lib;W:\libxslt-1.1.22.win32\libxslt.lib;W:\libxmlsec-1.2.11.win32\libxmlsec.lib

Now do the build in Debug mode with VS 2008 Express Edition.

You'll find mod_cspace.dll in [LOCAL_REPO]\build\win32\vc\apache2\Debug.

With this we complete building the module on Windows.

Now we need to configure SSL on WAMP. Please strictly follow the exact steps [with exact folder names and key names] in my previous post to do this. Don't miss a single step there.

Let's deploy our module in WAMP, now.

Copy mod_cspace.dll to c:\wamp\bin\apache\apache2.2.8\modules.

Now, let's edit httpd.conf [c:\wamp\bin\apache\apache2.2.8\conf]

Add the following to the file.

#Load mod_cspace.so
LoadModule cspace_module modules/mod_cspace.dll

#cspace_module configurations
<IfModule cspace_module>

#Make sure you give the absoulte path here to cscafile
CardSpaceCAFile "c:/wamp/bin/apache/apache2.2.8/conf/cscafile"

#Enable Cardspace login for php-sample web application
<Location /php-sample/>
UseCardSpaceAuth
</Location>

</IfModule>

Still, you miss two things.

- Download cscafile from here and copy it to c:\wamp\bin\apache\apache2.2.8\conf\.

- Download php-sample folder from here and copy it to c:\wamp\www.

All set... we are ready to GO...!!!

Start Apache server [if it is already running, stop and start] and type the URL https://identity-rp:12444/php-sample on your browser.

Okay... then... how do I know this works ???

We need to test our relying part web site with an Identity Provider.

Let's download WSO2 Identity Solution from here.

Unzip the downloaded ZIP file to a local folder [say [IS]].

Setting up the Identity Solution takes no more than 5 minutes... please follow the steps given here.

Startup the Identity Solution and go to the link https://localhost:12443 .

There you can register your self and sign in. Once signed in, you can download an Information Card from there. This guide, which is a very short one explains all what you need to know.

Now, you are almost done. But still, we need to say our Identity Provider that I trust php-sample as a relying party web site.

To do that I need to upload the certificate of this RP to my Identity Provider [IdP]. How to register a RP certificate with the IdP is explained here [look for "How to register your trusted Relying Party? "].

Still you have a question, I guess. How do I get the certificate of my php-sample [RP] ???

On IE 7, when you are at https://identity-rp:12444/php-sample - just right click the page --> Properties --> Certificates --> Details --> Copy to File --> Select 'DER' format --> Give a file name [e.g. site.cer] and save the certificate.

Are we done now..? Of course almost.. but, still there is something I skipped.

Remember the file "cscafile" ??? - which you downloaded from here.

This file contains public certificates of all the Identity Providers, who are accepted by the RP web site.

For this case you need not to do anything with this file - since I have already added the default public certificate of our Identity Provider - which ships with the Identity Solution.

But, in case you want to make this work with any other IdP, you need to get it's public certificate and add it to the cscafile file.

This is how you do it.

On IE 7 go to the IdP site --> just right click the page --> Properties --> Certificates --> Details --> Copy to File --> Select 'Base-64 Encoded' format --> Give a file name [e.g. site.cer] and save the certificate --> Open the saved certficate in notepad --> Copy and paste its content to cscafile.

Okay, finally we are done.

Hit the url, https://identity-rp:12444/php-sample and click the link "Login to this site" to initiate the InfoCard login.

WSO2 joins as a founding member of the Information Card Foundation

More details available here...

OpenID integration of WSO2 Identity Solution [Podcast]

http://wso2.org/library/3518

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 identity-dev-request@wso2.org and post your questions there.

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

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 https://is.test.wso2.org 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 https://is.test.wso2.org 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 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.

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!

WSO2 Mashup Server v1.0 Beta added Infocard support...

WSO2 Mashup Server v1.0 Beta released recently, supports Infocard login.

Please visit Mashup Server community site, Signup for a new account, Signin and register a Personal Infocard with your account. Now you can login with your Personal Infocard.

Link to register your Infocard is available on your profile page.