|
With today's ever-increasing demands for robust security software and systems, alternative authentication and trust mechanisms are gaining popularity. In particular, the user name-password authentication model is typically the root cause of many security frauds. Why? First, many of us record passwords somewhere, rendering them vulnerable for snooping. Second, our tendency to create passwords that are easy to remember makes them easy to be guessed or detected. Consequently, enterprises that have established processes along that model are looking for ways to better safeguard and optimize their systems without major overhauls.
Enter Windows CardSpace (henceforth, CardSpace), a Microsoft-led specification that has been gaining recognition over the past months. CardSpace defines a simplified paradigm that employs a security token called InfoCard for managing digital credentials and is available in Windows XP and Vista.
OpenSSO is Sun's open Web access management project based on Sun Java System Access Manager source code. As part of the open-source Project CardSpace on java.net, ICSynergy has extended OpenSSO to include CardSpace as a simple authentication module. In addition, ICSynergy offers a commercial CardSpace implementation for OpenSSO and Sun Java System Access Manager along with training programs.
This article describes the benefits, basic architecture, and process flow of the CardSpace-OpenSSO authentication module.
Contents
CardSpace clearly defines the trust model and mechanics for both the server and the client. Taking advantage of its constructs, such as those related to Security Assertion Markup Language (SAML)—xmldsig being an example—you can create or customize a toolkit to suit your needs. Recall that the goal for the authentication module is to build an alternative system to replace the user name-password model so as to reduce or eliminate the dependency on antiquated approaches. An important aspect of furthering that goal is a plan to smoothly transition users to CardSpace.
Authenticating with CardSpace is straightforward: Users supply their InfoCards to gain access to Web sites. Behind the scenes are the trust modules, an example of which is spotlighted later in this article. Figure 1 depicts the process flow.
Figure 1: Process Flow of Authentication Mechanism With CardSpace
|
Benefits
A major benefit of InfoCard is that it can store and supply common attributes, known as claims, such as email and shipping addresses. Typically, claims are nonsensitive data that enables CardSpace-aware sites to transact services according to the InfoCard values. As part of the card selection process, Web sites that support InfoCards can mandate that users specify their claims. Two major gains as a result:
- Time savings and reduced errors in the data
- Flexibility in selecting claims according to the site in question
In more advanced designs, you can expand the claims to include data that is more sensitive.
User Interface
Where do users store their InfoCards? In CardSpace's CardSelector, a virtual wallet filled with cards that users create or that are issued to them through trusted sites. Upon arriving at a CardSpace-aware site, a user is prompted by the CardSelector to choose the appropriate InfoCard that reflects his or her relationship—customer, employee, and such—with the entity. Figure 2 shows a typical interface.
Figure 2: Managing InfoCards on CardSpace
|
The CardSelector also delivers other capabilities. For example, in managed-card scenarios, the CardSelector functions as a token and information broker. Read on.
InfoCard Types
CardSpace supports two types of InfoCards:
- Self-Issued InfoCard, which users create with the CardSelector and specify where to use that InfoCard for authentication. Web sites that support self-issued InfoCards usually require registration to establish trust between the users and their associations with the sites.
- Managed InfoCard, which is issued to users by a trusted identity provider (IdP): someone who can truly attest that the users are who they purport to be. The CardSpace specification clearly defines the responsibilities and roles of managed cards and server-side components.
A good example is online banking. In Web transactions that involve transmission of trusted data—such as financial information—a trust model among the users, the IdP, and the site that accepts the InfoCard (usually the bank) is a must.
This section highlights the structure and process flow of allowing a user, Martin Gee, to access applications with CardSpace and OpenSSO.
Components and Goals
A CardSpace architecture contains two major components:
- A server-side component, which supplies the InfoCard's consuming services and the required capability for access management. An example is the OpenSSO server, which comprises the following:
- A configured OpenSSO instance, which runs in your Web container. ICSynergy has developed this authentication module with Apache Tomcat and will soon move to GlassFish, the open-source project of Sun Java System Application Server.
- A Secure Sockets Layer (SSL)-enabled Web container, with which the CardSelector transmits InfoCards. The transmissions occur over SSL channels only, which means you must generate real certificates from a Certificate Authority. CardSpace does not support nontrusted certificates.
- An authentication module, which consumes InfoCards and claims.
- Auxiliary access management services, for example, sessions and policies.
- A client-side component, which transmits InfoCards through the CardSelector. This is a configured Windows client with the Internet Explorer 7.0 or Firefox browser and the appropriate CardSpace extension. For non-Vista machines, install the .NET 3.0 runtime.
Note: Non-Microsoft CardSelectors are now available. Just be sure to install and configure the latest .NET runtime. For resource pointers, see References.
With the authentication capabilities in place, next comes the design of a process with the following services:
- Secure transmission of InfoCard claims to the protected applications
- Auxiliary registration for users
- Migration of users from outdated authentication systems
Process Flow
The concept behind the topology described in the preceding subsection and the user process flow is that OpenSSO supports the CardSpace capability while the protected application need not be aware of how to consume InfoCards, hence affording improved flexibility in scaling, reduced maintenance, and tighter security overall. Figure 3 illustrates the process flow of OpenSSO with a loosely coupled, CardSpace-enabled application.
Figure 3: Process Flow of CardSpace-Enabled Application
|
The yellow triangle depicts an OpenSSO Policy Agent that governs Web traffic to the application by enforcing the policy rules on user authentication, URL, subject, authentication module, time of day, and so forth. This architecture takes advantage of a Policy Agent capability to inject trusted data into the HTTP flow to the protected application and, subsequently, to share InfoCard claims.
Here is the process for a first-time user of InfoCard access:
- From the InfoCard prompt screen, managed by Open SSO, the user, Martin, clicks Log In. See Figure 4.
Figure 4: Prompt Screen for Authentication
|
The screen for choosing an InfoCard is displayed. See Figure 2.
- Martin chooses the appropriate InfoCard.
Because this is a first-time access, the screen shown in Figure 5 is displayed, asking whether to link the InfoCard to the user's account. This is the starting point for ICSynergy's lightweight transition from the user name-password authentication model to the highly secure InfoCard model.
Figure 5: Transition Screen for Account Links
|
- Once Yes has been clicked, CardSpace prompts the user to log in to OpenSSO to perform that step. See Figure 6.
Figure 6: Prompt Screen for Logging In to OpenSSO
|
- Martin logs in with his user name and password. See Figure 7.
Figure 7: Login Screen
|
- As soon as Martin's credentials have been authenticated, he is notified. At this point, the transition from the user name-password authentication model to the InfoCard authentication model is complete. See Figure 8.
Figure 8: Acknowledgment of Successful Login
|
- In this architecture, when Martin clicks Requested URL, the OpenSSO screen for editing the user profile is displayed. See Figure 9.
Figure 9: OpenSSO Screen for Editing User Profile
|
This article summarizes a typical security architecture, including the registration process, designed with CardSpace and OpenSSO. Future articles will address managed cards in greater detail.
Given a well-orchestrated transition process, the InfoCard is a viable alternative to the antiquated, increasingly risk-prone user name-password authentication model. As with new technologies, educating end users and support personnel is a major, often challenging task.
Inasmuch as it's a natural fit for the eCommerce arena, CardSpace will likely be widely adopted in the B2C world. On the horizon, even though they might take a while, are sophisticated developments in combining CardSpace, federation, and Web services.
Do visit Project CardSpace. Our goal is to distribute the authentication module as part of OpenSSO. Come join us!
|
 Martin Gee, chief technology officer of ICSynergy International, is a renowned thought leader and Web technologist who has developed innovative business, SOA, and identity-related solutions for numerous world-class companies in the last decade. His recent publications included ICSynergy's federation business blueprints and SAML 2.0 training courses.
|
|
Print-friendly Version
