Information Cards for Active Directory Users

In this article I discuss about an open source solution to enable Information Card logins for Active Directory users.

OAuth + OpenID + InfoCard

This is an imaginary use case to demonstrate how OAuth,OpenID and InfoCards fit together.

1. User logs into Facebook with his user credentials.

2. User wants to share images from Flickr with Facebook.

3. OAuth comes into act now.

4. Facebook requests Request_Token from Flickr to access user's photos on his behalf.

5. Since user has not authorized the request, Facebook gets unauthorized Request_Token from Flickr.

6. Now, Facebook will redirect the user to Flickr for authentication.

7. User presents his OpenID at Flickr to get authenticated.

8. Flickr redirects the user to his OpenID Provider for authentication - say myOpenID.

9. User authenticates at the myOpenID with a registered Information Card.

10.On successfull login user is redirected back to Flickr.

11.Now, Flickr will ask the user - whether its okay to give Facebook the access to his photos - and once selected 'yes' - user will be redirected back to Facebook.

12.Now, Facebook will request an Access Token from Flickr.

13.Since the user has authorized - Flickr will grant the access token to Facebook.

14.Now, Facebook can access Flickr to get photos on behalf of the user.

15.Let me summarize what each technology is for.

OAuth - a machine authorisation protocol - gives permission for a system to access your account.

OpenID - provides decentralized single sign on.

InfoCards - provides phishing resistant authentication.

Deploying WSO2 Identity Solution over Active Directory

This post explains all the steps you need to know in deploying WSO2 Identity Solution over Microsoft Active Directory [AD].

Lets get started with setting up the AD.

I have setup my AD on Windows 2003 Server [IP:192.168.1.3] and it looks like as shown in the image below.

Let's first create an AD user, which can be used by WSO2 IS to access AD.

This user can be of any name, we'll just say 'identity'

Now we need to delegate the task, 'Read all user information' - to the user 'identity'.

[Users --> Right Click --> Delegate Control]

Done, with it. Lets create another user called 'prabath' - where this user represents any user in the AD - who can connect to the WSO2 IS and download an Information Card against his corresponding AD profile.

All set - we are done with the AD configurations - let's setup Identity Solution.

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.

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.

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

Select LDAPRealm.

Set LDAPRealm properties. You can find the availabe AD attribute names from here.

Set Active_Directory realm as the default.

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

Click on 'Claim Mappings'.

Click on 'Given name' and 'Email address' and do the claim mapping appropriately.

All set, hit the url https://localhost:12443 and login with your AD user credentials.

Now you can download an Information Card from WSO2 IS, against your AD account.

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.

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

Adding InfoCard login to a J2EE Web Application

This article by Dimuthu describes how to introduce CardSpace authentication to J2EE Web applications using WSO2's Identity Solution.

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.

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.

Infocards with myOpenID

This is the approach which, Kim Cameron mentions in his blog - in his proposal for OpenID - Infocard integration. Let's see how it works - myOpenID already supports this.

1. Go to myOpenID and signup for a new OpenID [if you already have a one from myOpenID this step is not necessary]- it is also possible to signup using a self-issued Infocard, in that case steps 2 to 5 are not necessary - those explain how to associate an Infocard with an existing myOpenID account.

2. Create a self-issued Infocard in your Identity Selector.

3. If you are aleady signed in to OpenID, sign out and go to the SignIn page.

4. Instead of typing your username and password, simply click on the link, "Sign in with an Information Card" - to select the self-issued Infocard that you just created, from the Identity selector.

5. Once you submit the Infocard, you'll be prompted for the myOpenID username/password to associate the Infocard you submit with your OpenID - this is only a one time step.

6. Now you are done. Whenever you are redirected to myOpenID for authentication you can simply login with your self-issued Infocard, which you registered with your myOpenID - OpenID.

Integrating OpenID and Infocard

Kim Cameron in his blog discusses an approach to integrate OpenID with Infocards. This basically adds phishing resistance to OpenID - where, once a user is redirected to the OpenID provider for authentication, he'll be using an Infocard for authentication. In other words - the OpenID provider will be acting as an Infocard Relying Party who accepts Infocards. In this case, personal Infocards can be used - where those need to be registered with the OpenID Provider, before hand. This approach will completely eliminate typing passwords always.

Kim Cameron's approach is very much different from what is proposed in this spec by Sxip Identity.This proposes a new term - 'OpenID Inforcard'. Please refer my previous post to see a demonstration on OpenID Infocards and this post to find the differences between normal Infocard and OpenID Infocard approaches.

Well, if we go by Kim Cameron's proposal, we need to modify the OpenID Provider in to an Infocard Relying party.But, what is the gain? We make the OpenID flow phishing resistance.Anyway, if that is the only benefit - do we have to (really) go ahead with it? There are many other approaches to make OpenID, phishing resistance without touching the current OpenID Provider implementation. One such approach is to use the SeatBelt plugin for Firefox. But, with this, are we asking 'too' much from the user, since we pass the responsibility of protecting from phishing, towards the user.Anyway - my final thoughts on this is, Kim's proposal will definitely will be a marketing plus for OpenID Providers, if they, themselves add the phishing resistance to OpenID flow using Infocards.

Going back to the OpenID Infocard proposal - I can't really understand the benefit. It's almost same as the normal Infocard approach, except the use of OpenIDToken inside the RequestedSecurityToken, instead of SAML. In this post Mike Jones lists the benefits of OpenID Infocards against 'normal' OpenID.

1. There’s no OpenID string to type when you use your OpenID
2. This is a phishing-resistant authentication method.
3. It lets you recognize and choose your OpenID visually, based on the card graphics supplied by the OpenID provider.

Yes - I agree with all, but is there a point of using OpenID Infocards[OpenIDToken supported] against Infocards[SAML supported]?

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.