Kapil Sachdeva's Blog - SmartCard Serenity

This week in San Diego we showcased the InfoCard and WS-Trust support by .NET Smartcard which basically hosts the Security Token Service (STS) . This STS generates the RSTR (Request Security token response) with signed SAML Assertion message in response to a RST (Request security token) message [Basic WS-Trust protocol for exchanging security tokens].

Normally as we all know that InfoCard system is part of Avalon/Indigo SDK BETA release (require .NET 2.0) and supports only self issued identity cards but for this demo we created a InfoCard System on .NET 1.1 and used WSE 2.0 SP2 to communicate to the STS hosted in Smart card.

Actually last year at Burton Catayst we did a similar kind of demo which showed hosting WS-Trust STS on Smartcard and implemented active profile of WS-Federation. In this demo we showed how user's identity can be secured stored and managed by Smartcard and can be used by InfoCard System on PC.

Below are some snapshots of the sample application and InfoCard selector GUI on .NET 1.1

1. Smart client application. [ A Service locator ]

2. Authenticate to Smart card.

3. Lookup for Service

4. Select a service

5. InfoCard Selector GUI (created by us, not same as that in Indigo)

6. Select the InfoCard. This GUI locates the InfoCard [Please note here it is the metadata] and show only the non-geeky part :). Data (user attributes) are in Smartcard.

7. Clicking on Show Details retrieve the data stored (corresponding to supported claims in InfoCard selected) in the Smartcard.

8. Clicking on submit sends to STS (in Smartcard) an RST and gets RSTR. Client application extracts the SAML Assertion from RSTR, embeddeds in the Soap Request to http://www.dotnetcard.com/Demos/InfoCard/wstrust-rp1/BlueMonkey.aspx.

Its been more than month I have blogged something.... was on holidays and before that busy preparing demo using Liberty LECP profile for SmartCards. This is what is described below:

LECP or Liberty-Enable Client & Proxy profile is specified in “Liberty Bindings & Profiles Specificatios“ [Section 3.2.5]. LECP can be briefly explained as a client that has, or knows how to obtain, knowledge about the identity provider that the principal wishes to use with the Service Provider. This client receives and sends Liberty messages in the body of HTTP requests and responses.

Flow Diagram for LECP profile is :

The Demo comprised of 4 elements.

1. Service Provider [SP], http://www.dotnetcard.com/Demos/Liberty-Catalyst/Liberty-sp/TinkuTinki.aspx
2. Identity Provider [IDP], http://www.networksmartcard.com/Demos/Liberty-Catalyst/Liberty-idp/LECP.ashx
3. Liberty UA : Internet Explorer + LECP ToolBar.
4. Trusted Module : SmartCard.

Demo shows the proof-of-concept for role of SmartCards in Liberty Federation/ID Management world. I designed a toolbar for internet explorer which does the interactions with IDP, SP and Trusted Module (SmartCard). In the figure above toolbar can be considered as UserAgent (UA). Below is the picture of the toolbar:

Illustrated Below are the detailed steps of the demo:

• Clicking on the LogOn button in the toolbar prompts for user to enter PIN to authenticate to SmartCard.
• On successful validation, a list of Service Providers (stored as Xml file in .NET SmartCard) is retrieved by toolbar and shown in Service Providers combo Box in toolbar. Options and AutoFill buttons also get enabled.
• User selects the Service Provider from the combo Box.
• UserAgent (here toolbar) sends the request to SP selected for getting the AuthnRequestEnvelope as specified in LECP [Section 3.2.5.2].
• SP sends AuthnRequestEnvelope to UserAgent, UA validates and process this message to retrieve IDP (if provided by SP).
• If AuthnRequest message is good and valid, UA helps doing the mutual authentication of Trusted Module (SmartCard here) & IDP based on some shared secret. This scheme (authentication) has been used for demo purposes, we can make it as sophisticated as required.
• On Successful authentication, UA (toolbar) sends the AuthnRequest received from SP to the IDP.
• IDP does the necessary validation and processing of message and generates the AuthnResponseEnvelope containing the assertion about the user.

AutoFill button on the toolbar is a nice application to fill the forms on web pages from user data retrieved from SmartCard.

I used .NET for all the pieces necessary for the demo. .NET SmartCard is used as a TrustedModule. Below is shown the contents of the .NET SmartCard.

Lets have a look at Card Contents:

• Liberty.TM.exe is the application doing mutual authentication with IDP. 
• Liberty.ITrustedModule.dll is the interface to Trusted Module Service.
• AutoFillOptions.xml : Contains the user data (eg Name,address etc)
• ServiceProviders.xml : Contains the list of Service Providers supported by this SmartCard.
• Assertions.xml : This is another very interesting part. This is a cached assertion inside the SmartCard and to be used for offline mode. There may arise a need that Service Provider is not online so user can always download the assertions from IDP and present it to SP offline.

Last week at Microsoft Hospitality suite in Burton Catalyst conference I showed a demo showing the roles smartcards could play in Webservices security & federation. Demo comprised of 2 webservices - AirTicketService & CarRentalService, a company portal (TravelPortal)  and .NET SmartCard hosting Security Token Service (STS) , Pseudonym Service.  Also used was my WS-Federation implementation from Plumbwork workspace at GDN.

Objectives of the demo were :

• .NET SmartCard as a server hosting STS and Pseudonym service.
• Seamless integration of .NET SmartCard with WSE 2.0.

Following were the steps of the demo :

1. User goes to the company Travel portal and presents the pin to authenticate to the smartcard.
2. Travel portal on successful authentication to the card send RST (Request Security Token message) to STS residing in smartcard to get the token for AirTicketService. I used a custom token with has a symmetric key encrypted with public key of the requestor.
3. Travel portal then signs and encrypt the request to airticket service with the token retrived from card.
4. Airticket service after receiving the signed and encrypted makeReservation request, sends the GetPseudonym message to the pseudonym service residing in smart card
5. GetPseudonymResponse is returned by the smartcard containg the attributes of the principal.
6. Similar steps happen for the CarRental service.

The demo basically depicts figure 6 of the IBM/Microsoft paper on federarion.