Tuesday, November 11, 2008

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