August 18, 2007

Windows CardSpace is a new technology in the .NET Framework 3.0, which simplifies and improves the safety of shared resources and personal information on the Internet. It helps developers to build Software and Web sites which are more secured to the most commonly identity-related attacks such as phishing.

This technology helps to solve the problems of traditional online security mechanisms by reducing reliance on user names and passwords. Instead, it uses a separate desktop and cryptographically strong claims-based authentication. Windows CardSpace can facilitate more secure online experiences such as online shopping, banking, and bill payment.

Windows CardSpace is a central part of Microsoft's effort to create an Identity Metasystem or a unified, secure, and interoperable identity layer for the Internet. It enables users to choose from a portfolio of their digital identities and use them in contexts where they are accepted, independent of the underlying identity systems where the identities originate and are used.

Participants in Identity Metasystem

Windows CardSpace participates as an Identity Selector within the framework of the Identity Metasystem, a web services framework that utilizes WS-*protocols to communicate claims between three parties: the Identity Provider (IP), the Relying Party (RP), and the Identity Selector.

• Identity Provider : An IP as the name suggests, provides a digital identity for a user. For example, a Government agency, which issues a Social Security Number, is an IP.
• Relying Party : A RP is an application, which is in some way relies on a digital identity. A digital identity is the set of information contained in the claim that makes the identity's Security Token. RP frequently uses a digital identity to authenticate a user and then make an authorization decision, such as allowing user to access information.
• Identity Selector : An IS is a mechanism that prompts the user to choose one of the "Information Cards" and match the types of claims required by the Relying Party. An Information Card is a pointer to the data owned/managed by any number of different Identity Providers.

Architecture

There is no restriction of the CardSpace as an Identity Selector, IE as a browser, or ASP.Net as a web technology. To support, CardSpace, a browser has to support object tag or XHTML tag and must have an extension that supports CardSpace.

In order to interact with the service provider, a browser needs to follow some interaction patterns. To achieve this, a browser has to have some additional capabilities like ability to trigger an identity selector, pass the policies of Relying party to the identity selector, getting back the encrypted security tokens to the Relying Party and so on. Hence the browser requires the extensions in order to have these capabilities.

Extension for Firefox has already been released. Internet Explorer 7 (IE7) is shipped with all these capabilities inbuilt, so we do not require an extension for IE7, but we require extensions for lower versions of IE.

IE supports CardSpace using MIME handler extension called Microsoft Information Card IE helper extension. This MIME handler is then linked to object tag and this handler is then responsible for triggering an identity selector, passing the policy requirements to it, and returning an encrypted security token back to the service provider.

Figure 1 : Interactions among the Identity Selector, Browser, and Extension

CardSpace on a system

Let us see how one of the three participants is involved in the whole transaction i.e. Identity Selector. The identity selector is only an interface that is used by the user in order to communicate with Windows CardSpace installed on the user’s system. Figure 2 explains the architecture of what we have on our client machine or user’s machine when we say that we have card space installed on our system.

Figure 2 : CardSpace on our system

As figure2 suggests there is a card store, which is basically the collection of information cards installed on our system. Also we have an Infocard service that is running on the local systems. This service has two parts, Identity Selector and Store Abstraction. Both of these parts make the use of security capabilities of Windows. Store Abstraction makes use of DPAPI (Data Protection API). DPAPI provides a way to protect the piece of data and the data is encrypted using a key so that only a particular user can access that data. Identity Selector makes the use of WCF (Windows Communication Foundation) in order to communicate with different identity providers. It also uses different certificate API.

Different applications that interact with this service are shown with three different boxes on the top. The vehicle or agent, through which users access the web sites or web services, is a browser. Second application that interacts with CardSpace is WCF or Indigo. Third application is a control panel applet that allows the user to manage his/her identities.

All these applications call the service through the helper code. In case of a browser, CardSpace uses icardie.dll that in turn calls the Getbrowsertoken() API. In case of WCF application, CardSpace uses Gettoken() API. In case of control panel CardSpace uses manage() API.

The Infocard service shows some User Interface (UI)s, which need to be on a secured surface so that no other application running on the system can send in or receive any message from these UIs. Only the Infocard service can send and receive messages from these UIs. To implement a secured surface a process, UI Agent process, is used.

UI Agent process is created on demand by the service in the user logon session. It creates a separate Private Desktop and UI of the Identity Selector resides on this desktop, so that no application running on user’s desktop can communicate with the CardSpace.

There is also a notion of a secure desktop in Windows which is triggered when user presses keys Ctrl+Alt+ Del simultaneously. Private Desktop is separate from the Secure Desktop, but has the same characteristics as a Secure Desktop, such as user cannot access his/her desktop when he/she is on Private Desktop.

Figure 3 : Snap shot of the Private Desktop triggered by the UI Agent process

As the image shows, there is a separate Private Desktop and behind it, there is an Identity Selector(IS) UI. The IS is a snapshot or the bitmap of actual desktop, to preserve the context in which the user is working and triggered the Identity Selector UI.

Local STS

When self issued cards are used, the local STS come into the picture. Interaction of STS with other components is shown in the Figure 2.

In this case the user himself is playing the role of identity provider. When the user has to submit his self issued cards to the website or web service of the Windows, CardSpace requests the local STS for the Security Token. The Security Token in turn extracts the real credentials of the user from card store, prepares the security token, and submit it back to the Windows CardSpace.

Card Store Export

Consider a situation where we have to transfer our Information Cards to another system. For this purpose we have to export our cards from the card store to external storage device and then later import it in the card store of the remote system. The exported form of a user’s card store is a collection of Information Cards encrypted with a Key derived from a user specified password. An Information Card in an exported card store contains any additional housekeeping data maintained by an Identity Selector system beyond what was in the original Information Card issued by an Identity Provider. This metadata, including the content of the original Information Card, is referred to as the “Information Card metadata”.

An exported self-issued card also contains the master secret used for generating the token signing keys as well as any associated claims information for self issued tokens. This information is called “Information Card Private Data”. For managed Information Cards, the private data is obviously absent as that data resides at the managed Identity Provider. In environments where file extensions are used, the special file extension .CRDS must be used for an exported card store. A file named with extension CRDS and containing an XML document adhering to the structure and schema must be treated as an importable card store.

Supported Platforms

• CardSpace is supported on the Vista, XP, and W2K3 Windows platforms.
• CardSpace does not work on systems with a FAT32 root file system and works only on NTFS (updated 10 August 2006).
• OSIS is an open-source initiative to create an Identity Selector that runs on multiple platforms.
• Technically, participants in the Identity Metasystem are platform agnostic. As long as they speak the right WS-protocols, nobody cares what platform they run on.

Authors

Neha Tiwari is a Software Engineer with Impetus Infotech (India).