Identity and access control is a fundamental part of building connected systems. This chapter looks at Windows CardSpace, a client-side technology that authenticates users to web services and websites. By providing a simple and secure alternative to usernames and passwords via a consistent user interface that anyone can use, CardSpace is destined to become the preferred way to provide identities on the Internet and in federated applications.

There are people in their 50s in parts of the American midwest who have worked for cash all their lives, never left the United States, and never applied for, or been given, a Social Security number. When, at last, they come into contact with officialdom—a visit to a bank, a hospital, or a mortuary—there is a problem, a big problem: They don’t exist!

This is the exception, however. For most people in the developed world, it is only for the first few weeks of one’s life that one has no identity. Then a birth certificate is issued, one officially exists, and one has taken one’s first, baby step toward the modern world and delightful encounters with taxmen, banks, and utility companies.

Identity is a key part of everyday life. It’s required—implicitly or explicitly—in almost every interaction one has. If it’s taken away, misused, or abused, the consequences are frequently dire. Yet it’s only recently that most people have begun to care deeply about how their identity is used and by whom. This is, of course, a direct consequence of connected computer systems and the Internet in particular.

Prior to the advent of the Internet, it wasn’t really necessary to worry too much about one’s identity information—it was locked away, accessed only by people one trusted. Today, however, things are radically different. Googling one’s name can be an entertaining exercise—until one stops to consider that a potential employer will probably do exactly the same thing. Does one really want to publish details of what one gets up to in one’s (hitherto) private life—with photos—on one’s blog? People have been fired directly as a consequence of what they’ve put on their blog; managers are checking what employees put in their Facebook entries. Even if one has second thoughts and deletes a post, it’s probably cached in a search engine archive, on a company server, or in the Internet archive. After something is posted it is, effectively, permanently public.

These problems arise precisely because the Internet is so powerful. It’s easy to take for granted just how much it enriches everyone’s life. It would be extremely inconvenient if it were no longer possible to access a bank account, pay bills, or buy anything online. The Long Tail of the Internet (see the “References” section) has enabled a powerful new business model (“selling less of more”). Innovations such as web services, Ajax, and Really Simple Syndication (RSS)—and broadband access—have introduced a new wave of applications that some have felt the need to dub a part of Web 2.0 to distinguish them from their static, HTML-based predecessors. And who can imagine what the future will bring? Will new innovations such as pervasive, free wireless access lead to the Internet being even more deeply woven into the fabric of everyday life?

Despite all this convenience, power, and potential, many people are actually cutting down their usage of the web or are stopping altogether, particularly with respect to online purchasing (see recent studies by Gartner). It seems that just as the usefulness of the Internet is increasing, confidence in it is decreasing! The cause is problems with online identity.

Online identity theft, fraud, and privacy concerns in general are on the rise. Phishing and pharming are two of the biggest problems on the Internet today. And it’s not script kiddies having malicious fun; organized crime is reaping the misbegotten rewards. What are phishing and pharming? From www.antiphishing.org:

Research by Harvard University and the University of California at Berkeley found that good phishing websites fooled 90% of the participants on their study (see the “References” section). They also found that people are vulnerable, regardless of how computer-literate they are. In fact, it’s worse even than that: It’s currently possible to make a phishing site totally indistinguishable from a genuine site. One might be the foremost computer security expert in the world and still be fooled!

The severity of the problem has led to the Federal Financial Institutions Examination Council (FFIEC) recommending (see the “References” section) that banks and financial institutions should introduce multifactor authentication for high-risk transactions by the end of 2006. Their definition of a high-risk transaction is one that either allows funds to be transferred to other parties or that permits access to customer information. After these features have been removed from a bank’s website, there’s not much left! FFIEC field examiners will be measuring compliance.

A multi-factor authentication protocol requires more than one method of establishing the user’s identity. For example, instead of just entering a username and password one might also use a smartcard. Authentication methods are usually categorized as “something one knows” (for example, a PIN), “something one has” (for example, a card) or “something one is” (for example, a fingerprint). There are other categories but these are by far the most common. Combining different categories of authentication allows one to mitigate weaknesses in any particular method.

At the root of these problems is a flaw in the design of the Internet. There is no built-in system to handle identity, no “identity layer.” The Internet was built without a way to know who and what one is connecting to.

Consequently, everyone offering an Internet service has had to provide a workaround and we’ve ended up with a patchwork of one-off identity solutions. Personal information becomes bound to these islands of identity. There is no way to move Amazon.com book-purchasing history or Netflix.com preferences to, say, Barnesandnoble.com. A hard-earned eBay reputation cannot be used with other sites.

One might argue that although portability of personal data has clear benefits for the user, the island rulers will want to keep the information to themselves. This is probably a correct assessment in the short term, but in the long term, the benefits to sharing will outweigh those of hoarding.

At each site, one is obliged to use a new username and password combination in an attempt to be secure. (Don’t forget to look for an https: URL and a padlock symbol. It helps to know when one is securely connected to a phishing site!) One is trapped by the password paradox: The more secure the password, the more difficult it is to remember! Incidentally, the normal recommendation is to not write down passwords, but a strong password written on a Post-It is difficult to attack remotely. Anyone who gets hold of the Post-It can use the password, but this might be an acceptable risk. As always, security is about careful risk management rather than blindly following a set of rules.

The lack of a consistent way to handle identity has had dire effects in the enterprise arena, too. Whereas enterprises typically try to limit themselves to one central directory service, for example Active Directory, it is common to have hundreds of line-of-business applications, each with its own way of authenticating and authorizing the user (and storing the user data). Consequently, an astonishing amount of time and effort are spent on single sign-on (SSO): affording users the simple luxury of having to provide their username and password only once rather than for every single system they use.

Regulatory compliance also plays its part in the identity pain. A company’s information technology systems directly affect how the company controls financial reporting. Thorough financial auditing requires identity management and correlation of what users did and when they did it.

The emergence of service-oriented architecture in the enterprise—this is a book about connected systems technology after all—begs the question: “If, by using web services protocols, potentially anyone or anything with an Internet connection can access my application, how do I identify users and control access?”

How can this situation be improved? How can the Internet be made safer? How can phishing be prevented? How can a user determine that a site is trustworthy? How can the user securely and reliably authenticate without having to remember usernames and passwords? How can users’ privacy be protected, allowing them to control how and when personal information is disclosed? And how can business users authenticate to connected systems?

What’s needed is a simple, consistent, secure way of handling identity, one that is usable by everyone, that puts users in control of their identity and removes the walls between systems.

The obvious solution is for everyone to agree on just one way of handling identity. Fat chance? The industry has a history of moving away from proprietary technologies such as X.400 and token ring toward standardized, simple, open protocols such as TCP/IP (Transmission Control Protocol/Internet Protocol), HTML (Hypertext Markup Language), and SMTP (Simple Mail Transfer Protocol). The WS-* protocols have broad industry support; why can’t someone just devise an identity system for the Internet and have done with it?

Although this would be a great relief for everybody, it is important to realize that each of the technologies available today has its compelling use cases, its merits, and its faults. In short, it is an extremely difficult task to select a single identity technology that can satisfy all existing scenarios and, furthermore, anticipate every future scenario.

There are two classic approaches to complex computing problems like this. One is to have a very simple system with an extensibility mechanism so that it can be adapted to each problem domain (for example, SOAP [Simple Object Access Protocol]). The other approach is to add a level of indirection—an abstraction—that provides a consistent experience and hides multiple underlying technology implementations (for example, TCP/IP over Ethernet and token ring).

But before deciding which fundamental approach to take—and each has its advocates—it would be wise to examine previous efforts at solving the identity problem. One can learn from their successes and their failures—both technological and sociological—in a range of contexts. From that analysis, one can identify the characteristics that an identity system must possess in order to be successful.

Although there have been a number of efforts in this area, the two that spring to mind are Microsoft’s (much-maligned) Passport and Public Key Infrastructure (PKI). What prevented the Passport identity system from being successful? Well, that question’s a bit harsh: At the time of writing there are more than 300 million Passport users and more than a billion logons per day (Passport has been rebranded Windows LiveId). So, it is a success as an identity provider for MSN. However, as an identity provider for the Internet, it didn’t gain acceptance. For example, eBay used it for a while, but ultimately dropped it.

The problem is that Microsoft is the identity provider for every transaction. Regardless of whether one trusts the company—or believes it to be the very incarnation of evil—this arrangement is not always appropriate or desirable. When a user discloses his digital identity, only those parties whose presence is truly justified should be involved. One can formalize this requirement as follows:

This is referred to as the law of justifiable parties and it is one of seven “laws of identity” published and refined online at www.identityblog.com. Identity experts across the industry have directly influenced the formation of these laws via the blogosphere, helping to produce an industry-wide consensus that the laws are sound, accurate, and complete. This set of laws is one of the best tools available for evaluating new and existing identity systems.

The rest of the laws will be examined in a moment, but first stop to consider the case of PKI. PKI, as many of those immersed in it will vouch, is a wonderful technology that is set to take the world by storm. Unfortunately, PKI’s advocates have been saying this for a long time! There is no doubt that it is an extremely powerful and useful technology, but it can be costly, it can be complex to manage, and it is overkill in simple contexts.

Despite its flaws, PKI is the nearest thing to a universal identity system today. It is PKI that provides the security backbone of the Internet. SSL certificates allow secure transactions over the Web. If one were to build an Internet identity layer and were not averse to a bit of reuse, it might be prudent to take advantage of this existing infrastructure—provided it doesn’t cause one to fall foul of the laws of identity (see the next section).

It is revealing that even a strong technology like PKI, with a choice of vendors and identity providers (namely the certificate authorities), has not been universally deployed. Without being overly pessimistic, there probably isn’t a one-size-fits-all identity solution. For instance, it’s not possible to have a central authority for peer-to-peer systems.

It is this point, combined with the reality of a large existing installed base of identity technologies, that helps decide whether the “simple and extensible” or the “level of indirection” approach is most likely to gain traction and succeed.

In short, the indirection method has the greater potential. What’s more, it has the advantage of not precluding the simple/extensible approach. Nascent identity technologies can evolve under the all-encompassing wing of indirection. Perhaps, over time, one simple/extensible solution will become dominant—but it will still be able to interoperate with legacy technologies.

Therefore, what’s required is an identity metasystem or system of systems that provides that level of indirection, encompasses existing identity technologies, and obeys the laws of identity.

The Laws of Identity are an attempt to identify and formalize the characteristics required for any particular identity system to be successful. They have been derived by looking at many existing systems, examining their strengths and weaknesses, successes and failures.

Here are the seven laws of identity as stated at www.identityblog.com:

The laws are reasonably self-explanatory, but I’ll attempt to clarify or emphasize where appropriate. For a detailed explanation, take a look at the Laws of Identity whitepaper (see the “References” section).

The first law states that the user must be in control, be informed, and give consent before the system releases personal information. This law is at the heart of the oft-used term user-centric identity management (as opposed to domain-centric).

The second law and third laws are common sense: Identity information is sensitive, so reveal the minimal amount to the fewest parties necessary (this can apply to storage of identity data, too). For example, it is not a great idea to use Social Security numbers as student identifiers at U.S. universities. In fact, U.S. social security numbers can themselves disclose the year and state an individual was born in!

The fourth law says that an identity system should support both public and private identities. A website such as Amazon has a public identity. The more people who know that identity, the better. A private individual, on the other hand, might want to share her identity only in a point-to-point fashion, not broadcast it to the whole world. An example of getting this wrong is unencrypted radio frequency identification (RFID) tags in passports with a demonstrated reading range of 30 feet. Fortunately, the U.S. government is rethinking this bright idea.

The fifth law we’ve already covered. The sixth law emphasizes that the user is a fundamental part of the system, not an afterthought. A computer system that is in all other ways perfectly secure is fallible if it doesn’t account for the user.

The seventh law derives from the two laws that precede it. If one accepts that the human factor is crucial and there will be a mixture of operators and technologies, there must be a unified experience across contexts for the system to be usable. Even with multiple operators, technologies, and scenarios, one must try to have a consistent user experience.

So an identity metasystem is required. What does it look like? Well, it has to obey the laws of identity, expose the strengths of its constituent identity systems, provide interoperability between them, and enable the creation of a consistent and straightforward user interface over all of them. To be successful, it should also be completely open and nonproprietary: It is “the Identity Metasystem” not “the Microsoft or IBM or whoever Identity Metasystem.”

The Identity Metasystem is an abstraction of identity, a level of indirection above all the underlying identity systems. So, starting at the beginning, how does one abstract identity itself?

There are a myriad of different ways to identify someone or something and a multitude of different contexts. An identity can include physical appearance, beliefs, interests, likes and dislikes, reputation, and history. It might include such self-evident attributes as name, age, and address, but equally it could cover favorite author, eBay reputation, or purchasing history.

Key identifying characteristics can vary from one system and one context to another. To illustrate how one person’s identity information varies by context, consider that bank cards are appropriate at an ATM or a shop, passports at immigration control, and a coffee card (Your 12th cup is free!—an anonymous form of identity information) in a particular coffee shop. Try interchanging these! The key point is that each of us has many identities (or “personas”), depending on the context—and the abstraction should handle this. As simple as life would be with just one identity, in reality one needs different identities from different providers, and identity management involves context switching and maintaining multiple personas for the different relationships one develops and sustains.

Despite all this potential complexity, identity can be abstracted very simply. The identity of a subject can be always be expressed via a set of claims. Or, more formally:

If one tests this abstraction against all the types of identity mentioned earlier—or anything else one can think of—one can see that it fits very well: “Peter Pan is over 21,” “Bob’s Kerberos domain and principal are MSob,” “Bill’s credit limit is $5,000,” or “Alice knows symmetric key <x>.”

Incidentally, does one believe these claims? Why? Why not? Would showing a passport or driver’s license increase one’s level of belief in someone’s age? What if the Human Resources department at Microsoft were asserting that someone was a Microsoft employee?

The use of the word claim in the definition of digital identity is a subtle but deliberate choice. In a closed directory-based domain (for example, a Windows Server 2003 domain), one typically deals in security assertions, meaning “confident and forceful statements of fact or belief.” This confidence is well-merited: It is a closed, administered system. However, if one wants to have an open and broad-reaching identity system, it helps to reflect the element of doubt inherent in dealing with parties on the Internet. How confident one is in the veracity of a set of claims depends on who the identity provider is, their reputation, and one’s relationship to them. Oh, and also whether the claims have arrived intact, without being tampered with.

This claim model is extremely flexible—one can express a subject’s identity in pretty much any way one chooses to. This enables one to tackle the concerns of the general public around privacy and anonymity. On the Internet—even more than elsewhere—one’s natural desire is to remain anonymous until the moment one chooses to reveal one’s identity, and even then one wants to disclose the minimum amount of information possible (for example, revealing that one is over 18 without revealing one’s precise age). But how can an identity system preserve anonymity? Surely anonymous identity is an oxymoron?!

Well, anonymity is as much a part of identity as recognition. Many existing identity systems rely on unique identifiers (for example, security identifiers, or SIDs, in Windows). This is a critically useful constraint (to say the least), but not necessarily a constraint one always wants to apply. This is a flaw in uniform resource locator (URL)–based systems—by their very definition, they resolve to a location.

The key idea is that identifying a subject needn’t have anything to do with knowing who that subject is in the real world. One can use a pseudo-identity to represent a user, not a real identity, and associate that with zero or more claims. The fact that a certain user has a consistent pseudo-identity over time allows one to learn about that user without having any idea of who he really is.

Summarizing, a subject’s digital identity is going to be represented by using a set of claims supplied in a secure and verifiable way by an identity provider. The claims are packaged in a security token that can travel over process and machine boundaries to wherever they are required.

There are three roles in the metasystem:

To give but one example to illustrate the roles, when one buys a book online one is the subject, one’s bank is the identity provider giving one’s credit card details, and the online bookstore is the relying party consuming those details, enabling one to buy a copy of The Idiot’s Guide to PKI.

An identity is packaged in a security token containing claims made by an identity provider. In the preceding example, the online bookstore might specify that it requires a token that contains one’s name, address, and credit-card claims. One can then ask one’s bank to provide the required security token with proof that it was issued by them plus a way to prove one is the rightful possessor of the token. When one gives this token to the online bookstore, it verifies that it came from one’s bank and that one is the rightful purchaser, and then it extracts the claims and completes the transaction.

Notice here that the user is at the center. Potentially the token could have gone directly from bank to bookstore—from Identity Provider to Relying Party—but instead it goes via the user so that the user has control and consent over the release of identity information. There might be other communications between the Identity Provider and the Relying Party, but the flow of identity information should be under the control of the user, as per the first law of identity. In essence, what one is trying to do is to get a security token containing claims from the Identity Provider to the Relying Party under the consent and control of the user. The protocol at its simplest is

In traditional models, the Identity Provider and Relying Party are confined to the same domain, but this model is more generic. Here is the Identity Metasystem protocol in more detail (Figure 8.1).

Figure 8.1. Identity Metasystem architecture.

Note that everything is abstract here—nothing has been said yet about how one might implement this using specific technologies. The token can be in any format. There is no dependency on the client, so provided that the Relying Party can understand the token (and ask for it) and the Identity Provider can supply the token (and say that it can), we’re OK.

Step 5 deserves further explanation. When the user requests a security token, he has to authenticate to the Identity Provider in some way. The Identity Provider does not simply give a token to anyone who asks (imagine one’s bank is being asked for one’s account checking balance, for example). The client has to have the right to ask for the token. This step of providing a set of credentials to an Identity Provider to get another set of credentials for a relying party can be confusing, but it is straightforward to understand when one considers a few examples. It’s what happens when one applies for a passport: one has to provide one’s birth certificate or other documents to prove one’s nationality; one set of credentials (birth certificate) is exchanged for another (passport).

Drilling a little deeper into the model, there are a number of requirements for the system to work. Firstly, the Relying Party needs a way to specify the claims it requires in a way that everyone understands: “I need first name, surname, and address claims.” Likewise, the Identity Provider needs a way to specify the claims it is able to supply.

Secondly, the Relying Party and potential Identity Providers might use completely different identity systems with different token formats—this is a metasystem, remember! So, both types of entity need a technology-agnostic way to express the kinds of security tokens that they understand: “I need a SAML (Security Assertion Markup Language) 1.1 or Kerberos token.”

Furthermore, it would be useful if the Identity Provider and Relying Party could negotiate the types of claims they can use: “I can provide tokens of these types: X, Y”; “I can receive tokens of these types: Y, Z”—”Okay, let’s use token type Y because we both understand that.”

This is a bit like people communicating via languages and raises an interesting idea. If one person speaks English and French, and another speaks only Japanese, Swedish, and German, they can still communicate provided they can find someone who can understand, say, French and Japanese. Provided they can trust that person to translate accurately, they can interoperate perfectly well.

Within the context of an identity system, one might have to translate not only the type of token but also the claims themselves. For example, an Identity Provider might provide a “date of birth” claim, but the Relying Party might require an “older than 21” claim (information minimalization). Or a company might provide an “is at job level 1000” claim, but the Relying Party needs an “is a manager” or “is an executive” claim. This can all be handled by the Identity Provider.

What’s needed is a kind of token translation service: a trusted service that can receive security tokens of one type and convert them to security tokens of another type. One can refer to it as a security token service or STS.

Meanwhile, at the center of everything lies the user. Regardless of the complex flow of claims, tokens, and token types between the different systems within the metasystem, the user should have a simple, consistent, and comprehensible experience. One must be able to control the release of one’s identity information. Every time a user provides their identity online he should be able to use the same, familiar process.

These requirements can be summarized as follows:

Notice that up to this point, everything has been abstract. The Identity Metasystem is an abstract concept, but now it’s time to make some implementation choices.

The obvious choice for a set of open protocols that satisfy all the above requirements is some subset of the web services protocols (http://msdn.microsoft.com/webservices/). In particular, WS-Security, WS-SecurityPolicy, WS-MetadataExchange (WS-MEX), and WS-Trust. The WS-* protocols have wide support across the industry and, following the publication of the Microsoft Open Specification Promise (OSP; see the “References” section), they are available for anyone to utilize.

Some people ask about the Liberty identity protocols as an alternative to WS-*. There is a general convergence in the industry towards the WS-* protocols for web services. Unfortunately, these protocols simply were not available when Liberty developed its identity protocols. Liberty is developing their work to embrace the WS protocol suite and it is very much in the interests of everyone to make sure the WS protocols work across implementations. The question is becoming moot.

The interactions between the user, Relying Party, and Identity Provider can be implemented as a set of SOAP messages. WS-Security defines how to secure those messages and attach security tokens. WS-SecurityPolicy describes the security token and claim requirements of the Relying Party and capabilities of the Identity Provider. WS-MetadataExchange allows the querying and retrieval of these service policies.

WS-Trust is what breathes life into the Identity Provider. It extends WS-Security, facilitating trust between parties by propagating security tokens and performing claims transformation. The manifestation of WS-Trust is the Security Token Service, a web service that issues security tokens. In other words, to accept requests for security tokens, perform claim transformation, and issue security tokens, an Identity Provider needs to build a security token service implementing WS-Trust.

The following diagram (Figure 8.2) shows how the specifications relate to each role in the metasystem. The subject is typically the user but could be any entity.

Figure 8.2. Identity Metasystem architecture implemented with web services protocols.

There can be many relying parties, each with different token and claim requirements expressed using WS-SecurityPolicy. To access one of these relying parties, one can discover the corresponding policy using WS-MEX. Once one knows the requirements, one can choose an appropriate Identity Provider.

For example, a relying party might require SAML 1.1 tokens containing the user’s name and Social Security number from “any” Identity Provider. One selects one of the Identity Providers that is able to provide this kind of token.

The Identity Selector part of the metasystem has not been mentioned up until now. This is the consistent user experience part of the metasystem, interacting with the user, matching a Relying Party’s requirements to Identity Providers’ capabilities, making all the necessary web service calls, and allowing the user to be in complete control of how his identity is exposed and consumed. Windows CardSpace is an identity selector.

The Identity Selector is invoked by a client application when a Relying Party requires the user’s identity. The Identity Selector determines the Relying Party’s requirements and helps the user choose an appropriate Identity Provider. It sends that Identity Provider a request for a security token with the user’s credentials. When the response comes back, the Identity Selector asks the user to confirm the release of the token. It then passes the token back to the client application to be sent to the Relying Party.

So, what does the user interface (UI) of an Identity Selector look like? At a minimum, it has to help the user choose an identity provider that can meet the Relying Party’s requirements, and prompt the user for release of the token. So, each Identity Provider has to be represented in the user interface in some way and those that can meet the RP requirements should be distinguished from those that can’t. Hence the Identity Selector must have a way of knowing the capabilities of the IP.

One could just display the IPs in a couple of list boxes (matching and nonmatching), but it would be good for this to be as intuitive and user friendly as possible (law 6). Turning to the physical world for ideas, when asked for one’s identity, how does one provide it? By using business cards, credit cards, passports, driving licenses, identity cards, and employee (smart) cards. The blindingly obvious way to represent Identity Providers (and thus the user’s identities) is by using a card-based UI. Rather than a list box of names, have a bunch of images of cards for the user to choose from. Each card has a name and an image to make it clear which Identity Provider it represents and the ones that don’t meet the RP’s requirements can be grayed out. To know which IPs can meet those requirements, include some metadata (data about data) with the card that describes which claims it can provide, which token formats, where the security token service is, and so on. Now choose a file format for the card: Because everything has to be completely open (law 5), the obvious way to represent the card is via an XML document containing the metadata and an image of the card, signed by the identity provider who supplies the card to the user using XMLDSIG (XML digital signature). One can publish the schema, give it a .crd extension, and call it an Information Card.

And that, essentially, is it: an Information Card is an XML document containing identity metadata created and signed by an Identity Provider (Figure 8.3). It represents the relationship between the user and the Identity Provider. The card does not contain data about the user; it contains data about the Identity Provider: which identity claims the IP can provide (“SSN” not “123-45-6789”) and how to get a security token containing those claims. Signed, encrypted security tokens are what carry the user’s identity back to the client and on to the Relying Party. The only time a card travels anywhere is when the IP gives it to the user and the user imports it into the Identity Selector.

Figure 8.3. An Information Card (simplified for clarity).

Everything about the Identity Metasystem is designed to be completely inclusive, open, and nonproprietary. Anyone can build an Identity Selector—using whichever platform or technology he prefers—and many people are building them (for example, OSIS, Higgins and Bandit; see the “References” section). There will be identity selectors for Linux, Macintosh, and other operating systems, each taking advantage of native features and APIs. Indeed, an important measure of success for the metasystem will be its capability to build an end-to-end solution (Relying Party, client, Identity Selector, and Identity Provider) without using any Microsoft software whatsoever.

Windows CardSpace is an Identity Selector built by Microsoft for Windows operating systems, namely Windows Vista, Windows XP SP2, and Windows Server 2003 SP1. Version 1.0 ships as a part of .NET Framework 3.0 (Figure 8.4).

Figure 8.4. The UI of a card-based Identity Selector.

While it was in development, the codename for CardSpace was InfoCard. Many people became attached to the name, but it had one weakness (apart from being trademarked by someone else!). The term InfoCard was ambiguous: It could mean either the identity selector or the card. CardSpace has the virtue of being unambiguous. Windows CardSpace is an Identity Selector for Windows; an Information Card is the bundle of metadata (about an identity provider) that users import into whichever Identity Selector they happen to be using.

CardSpace can be launched by a client application via the GetToken() or GetBrowserToken() functions or by the user via a Control Panel applet (Figure 8.5). In Category View, it can be found under User Accounts.

Figure 8.5. The CardSpace icon as it appears in the Control Panel’s Category view.

When this is launched, after an initial splash screen the Select a Card to Preview dialog appears (Figure 8.6).

Figure 8.6. The initial card preview dialog.

This window and the other CardSpace windows are running on a randomly created, private desktop, in much the same way that the Windows Security dialog runs in a separate desktop (that is, the UI that appears when one uses the secure attention sequence, Ctrl+Alt+Del). This is a desktop in the Windows security architecture sense, not the normal “created by Explorer” sense.

It appears as if the normal desktop is grayed out and disabled in the background. However, it is in fact a bitmap of the screen captured when CardSpace was launched (with a mask applied). No matter how long one waits, the clock in the background will not update until one exits the UI! By running on a separate Windows desktop and limiting access rights, the bar is raised for the bad guys, making it more difficult to emulate the user experience, especially from within a browser.

CardSpace consists of two processes: icardagt.exe, running as the logged-on user, and infocard.exe, running as SYSTEM. The icardagt.exe process renders the CardSpace user interface and the infocard.exe process is the main CardSpace engine; they communicate with each another using a randomly created remote procedure call (RPC) channel. If Task Manager is visible when CardSpace is launched, these processes should be listed before the background is “frozen.”

Clicking on Add a Card gives the following dialog (Figure 8.7).

Figure 8.7. Add a Personal Card or install a Managed Card.

There are two types of card: Personal Cards and Managed Cards. Personal Cards—also known as Self-Issued Cards—are created and maintained by the user in the CardSpace UI. In other words, the user is the Identity Provider. This addresses a very common scenario: When one first registers at many websites, one creates a set of credentials: a username and a password. Likewise, CardSpace gives one the ability to log on and register using a self-asserted identity.

Managed Cards—also referred to as Provider Cards—are supplied to the user as a signed .CRD file by a third-party Identity Provider. This might be an employer, a financial institution, a government, or any other appropriate body. Cards are installed into CardSpace using the Install a Managed Card button or by simply double-clicking on the .crd file. How the .crd file gets from the IP to the user is left to the discretion of the IP (for v1.0, at least). It could be by email or by web download or a CD in the mail.

After installation, Managed Cards are stored locally in the user’s CardSpace store but the personally identifiable information associated with a card is not stored locally. The data is owned, stored, and managed by the Identity Provider who supplied the card. With Self-Issued Cards, both the card and the personal identity information associated with the card are stored in the user’s CardSpace store.

Semantically, Personal Cards and Managed Cards are identical. They both contain metadata that describes where and how the subject’s identity data can be retrieved. It’s just that for one type of card, that identity data is created by the user and stored locally; for the other type of card, the data is created and stored by a third party. In neither case does the card itself contain any personally identifiable information (PII) (for example, “Bill Gates,” “One Microsoft Way,” “Male,” or “+1 425 555 8080”). Cards contain metadata about where and how to obtain security tokens. It is the security tokens that contain the PII and are protected accordingly.

Although Personal and Managed Cards are conceptually identical, the difference in where the PII is stored has an important consequence for the implementation details. In principle, a user could provide any of the claims that a third-party Identity Provider might offer, they would just be self-asserted claims rather than IP-asserted claims. In practice, allowing users to create any claim they want to is not a good idea. The per-user CardSpace stores <Drive>:Users<username>AppDataLocalMicrosoftCardSpaceCardSpace.db (Vista) and <Drive>:Documents and Settings<username>Local SettingsApplication DataMicrosoftCardSpaceCardSpace.db (XP and Server 2003) contain Personal Cards, imported Managed Cards, and self-asserted PII. Of course the store is encrypted and ACL’d, but imagine for a moment that a user decides to store their Social Security number, bank account details, and pension information as self-asserted claims—it’s jolly convenient after all! No matter how hard it might be to break the security, the user has just created a honey pot for hackers.

To avoid this eventuality, the set of self-issued claims is useful but uninteresting and fixed (see Table 8.1).

None of the self-issued claims are particularly sensitive. It would be far easier for a bad guy to find this information in a phone book or a search engine than by trying to hack a user’s machine! The set of claims associated with a Managed Card is not limited in any way. It is for the Identity Provider to decide which claims are made available and how the data is stored and accessed.

Users can create as many Personal Cards as they want to. Typically, different cards will be used for different contexts. For example, the identities one might use at Xbox Live, Amazon.com, and commenting on online forums are going to be different. As reputation services begin to take advantage of Information Cards, users will choose carefully which cards they use to build a positive reputation.

Users can use many different cards at the same RP or one card at many RPs. The only things that restrict card usage are the policies of the RP and IP (and one’s own good sense).

Each claim has a URI to uniquely identify it. This is used in security policy, security tokens, and token-processing code. Note that the chosen namespace is not affiliated to any particular company (such as Microsoft) because many identity providers—including the self-asserted IPs of other Identity Selectors—will want to reuse these standard claims while adding other claims relevant to their domain (for example, healthcare or government).

Go ahead and create some Personal Cards (Figure 8.8) and experiment by exporting and importing them. Open the exported .crds file in Notepad to see what it looks like (it’s encrypted). In version 1.0 of CardSpace, exporting and importing like this is the only way to roam cards from one machine to another. Later versions will have more sophisticated provisioning and roaming capabilities. The .crds file format is documented in the CardSpace Technical Reference on MSDN (see the “References” section) enabling compatibility with other identity selectors. It is perhaps worth pointing out that after a Managed Card has been imported into CardSpace, the XML digital signature in the .crd file is no longer meaningful and is discarded. The .crds file has its own signature.

Figure 8.8. The CardSpace Edit a New Card dialog.

The user decides what values to assign the self-asserted claims. However, there is one claim in the table that doesn’t appear when one types claim values in the UI: the PrivatePersonalIdentifier (PPID) claim. This is not entered by the user, it is generated by CardSpace.

CardSpace and the Identity Metasystem can be used to provide any claim whatsoever. That said, which claim or claims should be used to uniquely identify a user? When someone registers with eBay or Amazon, how does the site know that it is the same person returning to the site each time? How can it customize pages for individual users, provide a purchasing history, and so on? Well, until the advent of Information Cards at least, it is the username that uniquely identifies a user, and it is the password that authenticates that user. Knowledge of a {username, password} pair “proves” that someone is the rightful user (probably).

With CardSpace, it’s slightly different. The Relying Party asks for and receives a security token signed by an Identity Provider. The user is uniquely identified by a combination of who the IP is (by means of the public key or certificate used to sign the token) and whichever claim that IP chooses to uniquely identify its users (a “user Id”). For example, the IP and user Id could be {government, SSN} or {employer, employee number}. This means the Relying Party has to know which claim the IP uses as a unique identifier for the user. The important point is that a Relying Party knows who the user is by knowing who the IP is and the user Id claim used by that IP.

Consider the case where the user is the Identity Provider, using self-issued claims and tokens. To be consistent with third party Identity Providers, a public key and a user Id claim is required. A 2048-bit RSA key pair is generated by the CardSpace system for signing tokens. The user Id claim is the PPID, also generated by CardSpace.

Thus for self-issued cards the information that uniquely identifies the user to relying parties is {RSA public key, PPID}. Typically a Relying Party will store a hash of these two values in a column of the user account database and use that to look up a user and his account history. Therefore, a Relying Party can consistently identify a user, regardless of the values of other claims. This, actually, is the true value of self-issued cards: an asymmetric key-based user credential. The other self-issued claims are useful, but claims from an IP other than the user are probably more valuable since they are asserted by a third party.

So, which claim should a third-party IP use to uniquely identify the user and how does the Relying Party know which claim is being used? The simplest solution is for an Identity Provider to re–use the PPID claim, particularly if it wants to adhere to law 2 (that is, choosing an identifier that is not overloaded with another meaning). However, it is entirely at the discretion of the Identity Provider which claim set it provides just as it is at the discretion of the Relying Party which claim set is demanded. The Identity Metasystem is as inclusive as possible.

On the other hand, a Relying Party might not need to uniquely identify a user at all. Maybe it just needs to know the user is over 21. In which case it can ask for an Age claim or perhaps an Over 21 claim, specify the IP as a government-run STS, and be done with it. Information Cards contain metadata describing which claims can be retrieved from an IP, where they are, and how to get them. For self-issued cards, the security token service is local and the data is stored on a local storage device. For Managed Cards, the security token service is hosted by the Identity Provider. The card and STS model can also be extended in other ways.

Future versions of CardSpace will support security token services on devices such as USB keys, smart cards, and mobile phones. These portable security token services (pSTSes) will provide a robust solution for roaming scenarios. Another potential implementation is to have “Information Cards in the cloud” where one’s cards are stored online—either by oneself or a third party—instead of on a hard disk. However, that begs the question, “How does one authenticate to the cloud?” That one is left as an exercise to the reader!

The portable STS solution is useful because it offers true portability plus greater security when using an untrusted client machine. Suppose that someone leaves on vacation just in the midst of a bidding war for a pair of Elvis’ pants on eBay. While travelling, the person decides to go into an Internet café and use one of the machines to place a new bid. The problem is that one knows nothing about the machine. It could have root kits and keyboard loggers installed and be lying in wait for someone fool enough to use Outlook Web Access, eBay, or whatever and have their credentials stolen. Therefore, anyone would be understandably reluctant to import their information cards onto this potentially compromised machine. With a portable STS, one doesn’t need to. Whether it’s via a USB port, or a smart card reader, or a wireless connection, one can use CardSpace to approve the release of a signed, encrypted security token from the pSTS. It is this that travels through the compromised Internet café machine (or via some other channel) and onward to the Relying Party. The malware on the machine is left impotent.

CardSpace consists of three main parts (Figure 8.9):

The central part of the system is the infocard.exe service, which handles all token and management requests and runs as Local System. On startup it creates the UI Agent process, icardagt.exe, and this runs as the user on a private desktop, communicating with infocard.exe via a randomly created RPC channel. Running the UI in a separate desktop helps protect personal identity information, mitigating phishing and shatter attacks and preventing disclosure of personal information. The UI process runs with an augmented access token (special logon SID) so that only that process can access the desktop. The UI is minimally functional to reduce the attack surface. For example, it does not render rich text and there is strict boundary-checking to prevent overflows. Likewise, it is not skinable: It is not intended to be a general purpose programming surface.

The store, cardspace.db, is ACL’d for Local System access only, and stored in the user’s profile. If the store is not present, such as when the user runs CardSpace for the first time, it is created automatically. CardSpace allows only that user account to have access. If several people share the same user profile, individual information cards can be PIN-protected.

Data in the store is encrypted. The store and individual cards can be backed up and moved onto other machines using the UI. When the user exports cards he or she is prompted for a password, which CardSpace uses to protect the exported .crds file.

One component, infocardapi.dll, handles all entry points into the CardSpace system and is loaded into the client application process. It intentionally has a very limited API. There are only four interesting methods (the others are Windows Communication Foundation [WCF] callbacks): ImportInformationCard(), GetToken(), GetBrowserToken(), and ManageCardSpace(). None of these functions outputs any information without the user’s consent. CardSpace is designed to be an interactive rather than a programmatic system. It will not release PII without explicit user approval.

When a client application uses WCF to access a service endpoint (Figure 8.10), WCF will retrieve the relevant policy (steps 1 and 2). CardSpace is just one way of providing credentials to a WCF service. A service specifies which type of credentials the client should use via the client credential type. There are several options depending on which binding one uses. When using message security, the options are None (anonymous), Windows, Username, Certificate, and IssuedToken.

Figure 8.10. Swim lanes for a Windows Communication Foundation client.

The IssuedToken policy assertion indicates that user credentials should be in the form of a signed token issued by a security token service. WCF will use CardSpace to get this security token if the transport is HTTP, HTTPS, or net.tcp and one of the following is true:

If this is the case, WCF will launch CardSpace automatically via the GetToken() method, passing in the RP’s policy (step 3). After CardSpace has interacted with the user and an STS to get a signed, encrypted security token, GetToken() returns the token for WCF to send to the Relying Party web service (step 9). Note that developers don’t call GetToken() directly, it is done for them by WCF.

GetToken() causes CardSpace and the CardSpace UI to be launched but before selecting a card and authenticating to a particular Relying Party, one first has to agree to release information to it. CardSpace checks the card usage history (aka the CardSpace ledger) to see whether the user has agreed to provide personal information to the site. If not, a special dialog appears—an “introduction ceremony”—providing information from the Relying Party’s SSL or Extended Validation (EV) SSL certificate (Figures 8.11 and 8.12). The dialog also appears when the user imports a managed card (Figure 8.13).

Figure 8.11. Introduction dialog for an RP using an SSL certificate.

Figure 8.12. Introduction dialog for an RP using an EV SSL certificate.

Figure 8.13. Introduction dialog when importing an updated version of an information card signed with the Identity Provider’s EV certificate.

This Introduction dialog is a vital cog in the defense against phishing attacks. CardSpace will only work with Relying Parties and Identity Providers that identify themselves with an SSL certificate, and one can only import a card or choose a card if one first makes an explicit choice to trust the associated organization and its certificate via the Introduction dialog.

If the certificate is a simple SSL certificate, the Introduction dialog will display the text This site does not meet Windows CardSpace requirements for a bank or major Internet business... and it will say that the organization name and the location are unverified (Figure 8.11). If, on the other hand, the certificate is an Extended Validation certificate, no such apocalyptic message appears (Figure 8.12). In the future, there will be additional information to help the user’s decision such as data from reputation services.

How does this help against phishing? Put simply, a certificate authority (CA) will issue an EV certificate to an organization only after it (the organization) has passed a rigorous, industry-defined validation process. Therefore, if one knows the website or service one is using is backed by an EV certificate, one can be confident that the site is genuine (incompetent CAs and software bugs notwithstanding). As the Introduction dialog indicates, banks and major Internet businesses will use extended validation certificates.

Internet Explorer 7 and contemporary browsers recognize EV certificates and make the address bar glow green as feedback to the user. CardSpace goes one step further by making the decision to send a card explicit and keeping track of which certificates the user has accepted.

Making this more concrete, suppose that a bank uses an EV certificate. When logging on to the bank’s website, the login page is secured using the EV certificate (via SSL) and the address bar glows a reassuring green. One can choose to log on using an Information Card and when the Introduction dialog appears, one reviews the certificate, and agrees to release information to the site. One logs on effortlessly many times over the following weeks without taxing the brain once about usernames or passwords.

One day an email arrives saying that one’s bank account information might have been compromised and to follow a link to the bank website to check the account. Of course, it’s a phishing email. A legitimate email should never have a link to the website in it but simply ask the user to log on as usual (whilst reminding them not to click on any links in emails). However, in haste, one makes a mistake—as happens to most of us from time to time—and with one click one arrives at a web page that looks exactly like the bank website’s login page. It is a phish!

At this point there are a couple of ways for the bad guys to get hold of the user’s credentials: Either one is asked for one’s username and password, or it’s an HTTPS page and one is asked for one’s Information Card (CardSpace v1.0 will not function with an HTTP web page).

In the first case, following weeks of bliss using one’s Information Card to log on, one doesn’t want to use username and password. If this site says information cards aren’t available, one’s suspicions should start to grow. Furthermore, without an EV certificate, the browser address bar will no longer be green.

If the bad guys support Information Cards (and face it, they’re usually technically advanced), they must identify their site with an SSL certificate. Because one hasn’t been to that site before, when one tries to use a card, the Introduction dialog will appear. One is alerted that something is phishy on three counts: The dialog has appeared even when one has already agreed to release identity information to the bank; the information from the certificate won’t match the bank’s details or logos; and unless it’s an EV certificate, there will be the This site does not meet Windows CardSpace requirements... message.

Suppose that one is having a real off day and releases one’s credentials to the site. In the Choose a Card to Send dialog, none of the cards will have been used at the site before, but one goes ahead and chooses one anyway. One doesn’t bother to look at the site history of the card showing the date and time when one last visited the genuine site. And so a signed, encrypted security token is sent to the bad guys who decrypt the contents using their SSL certificate. However, it’s still not much use to them because although they have access to the claim values if they try to repurpose the token to log on to the bank website proper (backed by a different certificate), they’ll break the signature.

Furthermore, if the card selected is backed by a smart card or other device—and it should if it’s a bank card, according to the FFIEC—the bad guy has to steal that, too. Therefore, even if the bad guy manages to persuade a user to back up all their information cards to a .crds file and email it to him (with the PIN) or he steals a laptop, he still won’t be able to gain access to one’s bank account.

This touches on the topic of card revocation. If a machine is stolen, Vista’s BitLocker feature will make it more difficult for the bad guy to gain access to data but one should still revoke one’s cards, in much the same way that cards are revoked in the physical world when they are lost. For Managed Cards, one simply contacts the IP. It will then block all access using the stolen card’s card ID and issue a replacement .crd file. For Personal Cards, the thief will have both the card and the IP. In that case, the RP will need to be contacted to remove the stolen card’s public key and PPID from the associated user account.

When contacting the RP or IP to revoke one’s cards, typically using a Lost or Stolen Cards web page, it will be necessary to authenticate oneself. If one’s cards are backed up somewhere they can be used on another machine. Otherwise some fallback mechanism is required, such as supplying an email address and answering a security question or two. Associating a new card with an account is straightforward.

And now back to the Introduction dialog...

Once the user has explicitly agreed to release their credentials to a Relying Party, the Choose a Card dialog will appear directly on each subsequent occasion unless either the RP’s certificate details change or its privacy terms have changed.

The Identity Selector module in infocard.exe uses the RP policy to determine which cards match the RP’s requirements. The UI process, icardagt.exe, displays the cards to the user with nonmatching cards grayed out. The ledger keeps track of the sites where a card is used with the date and time of last usage. Cards that have been used at the RP in the past appear at the top of the Choose a Card dialog.

When the user selects a card, CardSpace knows which Identity Provider to contact from the card’s metadata. Included in the metadata is a MEX endpoint and CardSpace retrieves the IP/STS’s security policy via a WS-MEX request and response (steps 5 and 6). It then sends a Request for a Security Token (RST) message to an STS endpoint asking for a security token matching the Relying Party’s policy and providing the user’s credentials (step 7).

Whereas the Identity Metasystem will accommodate any method of authenticating to a security token service—including round-tripping—CardSpace version 1.0 is limited to four authentication methods for external STSes. Naturally, for self-issued tokens, the local STS doesn’t require an additional authentication step and the MEX and RTS/RSTR messages are optimized. If the user chooses a Personal Card, infocard.exe goes ahead and creates a SAML 1.0 or 1.1 security token (which version depends on RP policy) using data stored locally in the CardSpace store.

The four methods of authentication for Managed cards in CardSpace version 1.0 are

Some of these credential types require additional user interaction. With Kerberos and personal information card authentication, the user simply chooses the card. With a hardware-based X.509 certificate, the user will be prompted to engage the device (for example, insert a smart card into a smart card reader and type a PIN). With username and password, the user will be prompted for his password. Hardware-based X.509 certificate means any certificate-based device that has a Cryptographic Service Provider available for it.

All communications between CardSpace and other parties are encrypted as appropriate (including MEX calls). How the contents of the RST and RSTR messages are encrypted depends on the credential type used. The Information Card contains metadata about the security binding, and the security policy is also retrieved via the MEX exchange prior to sending the RST (steps 5 and 6).

When username and password credentials are used, the channel is secured using SSL. For Kerberos, a symmetric key is used (included in a Kerberos V5 session ticket). For X.509 certificates, an asymmetric key pair is used. Authentication to an STS using a Personal Card can use either a symmetric or an asymmetric key pair for the security binding. For in-depth details on how this is implemented, please refer to the CardSpace Technical Reference and the WS-SecurityPolicy specification.

The Kerberos authentication method will dovetail nicely with Microsoft’s Active Directory Security Token Service (AD/STS)—or ADES 2.0—when it is released. System administrators will use an admin console to set up trust relationships with STSes outside the Enterprise domain, define which Active Directory attributes are exposed as claims, and define claim transformation. When a user wants to authenticate to a business partner’s site or service, she simply selects a company information card. All the necessary authentication and access control are done seamlessly via federated security token services.

After authenticating the user using the credentials in the RST and retrieving the required PII from its user database, the IP/STS creates a security token containing the required claims and a proof key for the RP if required. (See the text following Figure 8.14 for more information on proof keys.)

Figure 8.14. Alerting the user when the RP’s identity will be sent to the IP.

CardSpace can include the Relying Party’s identity (that is, its endpoint and public key) in an <AppliesTo> element in the RST, in which case the token is encrypted with the RP’s public key. However, the default is to conceal the RP’s identity from the IP in order to protect the user’s privacy.

If the RP wants its identity to be given to the IP, it can put an <AppliesTo> element in its security policy. The IP, on the other hand, can specify that an RP’s identity is mandatory (as per an “auditing STS”) or optional by putting a <requireAppliesTo> element in its Information Card.

The RP’s identity is always sent in the case of an auditing STS (unless the user cancels) and it is also sent if the RP identity is optional for the IP but the RP wants it included. CardSpace alerts the user if the IP will be given the RP’s identity, allowing her to cancel before the RST is sent (Figure 8.14). For full details on token scope, please refer to the CardSpace Technical Reference.

There is a classic trade-off here: increased security versus increased privacy. The benefits of providing the RP’s identity are that the security token can be encrypted using the RP’s public key so that only the RP can access the contents, and the IP can track where tokens are used. The benefit of not providing the RP’s identity is that the user could, for example, use her government IP to prove she is of a legal age at verystrongalcohol.com, but the IP will be unaware that the user identity was used for that purpose.

After the signed security token has been created, containing claims and a proof key for the RP, it is packaged into the RST Response (RSTR) message with, optionally, a display token to show the user what’s in the security token.

As the name implies, a proof key enables the user to prove to the relying party that she is the rightful bearer of the security token (it’s also known as a subject confirmation key). Between them, the client and the IP securely establish either a shared symmetric key or an asymmetric key pair with the private key held by the client. The IP includes its key (symmetric or public) in the security token intended for the RP. The client signs the message to the RP—which includes the token—using its key (symmetric or private). The Relying Party checks the message signature using the key the IP provides. If the signature is okay, the client possesses the key agreed with the IP and therefore must be the rightful bearer of the token.

Entropy for creating the symmetric key can be provided by the client and/or the IP. Asymmetric proof keys are always generated by the client. The only restriction is that tokens not encrypted with the RP’s public key cannot use a symmetric proof key because if the proof key were a shared, symmetric key, the RP would be able to reuse the token elsewhere without breaking the IP’s signature—and thus pretend to be the client! By default CardSpace asks for an asymmetric proof key unless the RP policy specifically requests a symmetric key.

For CardSpace v1.0, proof of possession with websites is determined by maintaining an HTTPS session between the client and the Relying Party (that is, proof is supplied at the transport level) and the token returned from the STS is a raw token (there is no proof key). The STS is asked for a token with no proof key and if it issues a SAML token, it is marked as a bearer token and includes an <AudienceRestrictionCondition> element restricting the token to the target site. After the CardSpace system has received a security token from the IP via an RSTR, the user is prompted whether to send the token to the Relying Party.

Relying Parties are required to have an X.509 certificate (preferably an EV certificate) to identify themselves and to allow security tokens to be encrypted using a session key protected by the certificate’s public key. This means that the security token is totally opaque to CardSpace! This is by design: Identity selectors need to be security token-agnostic. There shouldn’t be a requirement for CardSpace to understand every token that passes by. However, for users to give fully informed consent to the release of the token, they need to know what personally identifiable information is being sent to the RP.

The solution is for the IP to send an additional (and optional) display token to the user. When the user chooses a card, he knows which claims will be sent—it’s in the metadata of the card and displayed in the UI. If he wants to know the values of those claims, he can click on the Retrieve button. In that case, the RSTR includes the display token, secured using the IP’s security binding, and is displayed to the user. The question that invariably crops up at this point is, “if the security token is opaque, how does the user know that its contents are the same as what’s in the display token?”

Technically, it’s impossible for CardSpace to check that the two match because the claims can use any encoding whatsoever and are encrypted using keys that only the RP can decrypt. It’s those very properties (encapsulation) that let the Metasystem transmit claims from any one system to another. However, the display token and the security token are cryptographically bound together by the IP’s signature. The IP cannot repudiate claims after the fact (that is, they can’t say, “We didn’t send that”). If the claims shown to the user and the claims sent to the RP don’t match, the Identity Provider can be held accountable via human/reputation/legal processes. In other words, this is one for the lawyers and this is where real-world solutions to breach-of-trust will have to reside.

After the user has approved the release of the token, it is handed back to the client application via an out parameter of the GetToken() method (step 9). WCF then sends the token to the Relying Party (step 10). The recipient of the security token can be a service endpoint or an STS. The token is cracked open, the signature verified, and the user is authenticated and authorized using claims in the token.

For browser applications the flow is very similar (Figure 8.15): steps 4 through 8—how CardSpace operates—is identical.

Figure 8.15. Swim lanes for a browser client.

For websites, the canonical scenario is that the client—the browser—will try to access a protected web page (step 1a) and will be redirected to a login page (step 1b). The browser retrieves this page over HTTPS (steps 2a and 2b); there’s nothing new yet!

If the login page supports Information Cards, it will include a button bound to a particular <object> element:

<object type="application/x-informationcard" name="...">
  <param name="tokenType" value="..." >
  <param name="issuer" value="..." >
  <param name="requiredClaims"
    value="http://.../claims/givenname, http://.../claims/privatepersonalidentifier">
</object>

The type attribute is the key here, indicating that the object element represents an Information Card Identity Selector. This tells the browser to launch whichever Identity Selector is on the machine. One could use the classid attribute, but that would limit one to one specific identity selector (assuming the same classid wasn’t used elsewhere). The param elements contain the RP policy.

If the Relying Party doesn’t want to use an <object> element (for example, if the browser has disabled ActiveX support), the following binary behavior format is equivalent:

<ic:informationCard name="..."
  style="behavior:url(#default#informationCard) "
  issuer="..."
  tokenType="...">
    <ic:add claimType="http://.../claims/privatepersonalidentifier" optional="false"/>
<ic:/informationCard>

Both formats make it incredibly simple to add information card support to an existing login page. The RP’s policy is described not in WS-SecurityPolicy, but in simple HTML within the main element tags.

All that’s required now is a browser, or browser add-in/extension, that recognizes this format. IE 7.0, for example, ships with an icardie.dll file that handles this. Browsers that don’t recognize the format, such as IE 6 and earlier, will ignore the element completely. Likewise, if the .NET Framework 3.0 is not installed, icardie.dll fails graciously.

When the user clicks on the Information Card button (step 2c), the browser calls the GetBrowserToken() method, passing in the RP policy as an input parameter (step 3). Like GetToken(), GetBrowserToken() returns a signed and encrypted security token. However, unlike GetToken(), the token returned has no proof key; it is a raw token. All that the browser has to do when it receives the token (step 9) is to post it to the website (step 10). The Relying Party processes the token in the usual way (validation, claim extraction, lookup, authorization) and then it allows the user website access in precisely the same way that it does for users authenticating with a username and password. The most common method is to issue a session cookie (step 11).

This is the simplest scenario, but there are others. If the RP doesn’t want to do token processing on its front-end servers, it can specify a resource STS as the issuer and get the STS to do the token processing and cookie issuance (or whatever token the front-end servers require). Of course, if the resource STS supports information cards (that is, it has the <RequireFederatedIdentityProvisioning> assertion in its policy), the Relying Party can be its own Identity Provider and the user simply chooses the Relying Party’s Information Card. If it has an IssuedToken policy assertion with <Issuer> missing, empty, or set to self-issued token, CardSpace will ask the user to choose an information card (and an IP) to get a token to authenticate to the resource STS. One can have any number of STSs chained together in this way; WCF simply traverses the chain.

Identity Providers sign their security tokens with a private key so that the token recipient can validate the token and the issuer using the corresponding public key. Third-party IPs do this using an X.509 certificate. For self-issued tokens, CardSpace creates an RSA key pair.

However, if there is one key pair and one PPID per card, the user has the same unique identifier wherever she uses that card. This creates a privacy problem because any two Relying Parties can determine whether they have the same user and potentially collude.

To mitigate this, when the user creates a Personal Card, CardSpace generates a 256-bit random number called the master key and a globally unique URI called CardId. (Managed Cards also contain a unique CardId generated by the Identity Provider.)

When the user selects a Personal card to authenticate to an RP, the master key is hashed with either the RP’s public key if it’s an SSL certificate, or the OLSC (Organization, Location, State, Country) ID if it’s an EV cert. This hash is used as the seed for the Crypto API to generate a per-card, per-site RSA key pair, thus solving the collusion problem.

The Crypto API uses an ANSI X9.31-compliant algorithm to generate the RSA key pair so that the same master key and RP certificate will always produce the same RSA key pair. This means that when the card (including the master key) is backed up to a .crds file and imported to a different machine, the RP sees exactly the same user.

Similarly, the PPD is created by hashing the CardID with the RP’s public key or OLSC ID. This means a user can use the same card at multiple sites and there will be a different PPID and a different RSA key pair for each one. Relying Parties are unable to collude and track the user. In fact, this feature can be extended to external Identity Providers. A PPIDSeed can be sent in the RST so that IPs can present a different PPID to different Relying Parties even though the user selects the same card.

CardSpace displays the PPID to the user in a human-friendly form (Figure 8.16). The algorithm that converts the PPID into this form is very simple (Listing 8.1) and can be used by Relying Party sites to display PPIDs to the user. This is useful when the user has more than one card associated with an account and wants to delete one of them; for example, when the user wants to use a different card and/or revoke an existing one.

Figure 8.16. Human-readable version of the PPID.

public static string CalculateSiteSpecificID(string ppid)
{
    int CallSignChars = 10;
    char[] CharMap = "QL23456789ABCDEFGHJKMNPRSTUVWXYZ".ToCharArray();
    int CharMapLength = CharMap.Length;

    byte[] raw = Convert.FromBase64String(ppid);
    raw = SHA1.Create().ComputeHash(raw);

    string callSign = "";

    for (int i = 0; i < CallSignChars; i++)
    {
        // after char 3 and char 7, place a dash
        if (i == 3 || i == 7)
        {
            callSign += '-';
        }
        callSign += CharMap[raw[i] % CharMapLength];
    }
    return callSign;
}

One final note on security: Information Cards and CardSpace make life more difficult for the bad guys, but one shouldn’t make the mistake of thinking one is 100% safe: there is no such thing. No software is without bugs and no software is without security bugs. CardSpace is no exception: It will have bugs, security bugs, and vulnerabilities. As they are discovered, they will be patched and updates sent out via Windows Update. Computer security is about continually trying to keep one step ahead of the bad guys. However, CardSpace does represent a significant step forward in the fight against cybercrime and after people become accustomed to the convenience and the increased security that it offers, there will be no looking back.

That’s enough on architecture. For fine details on interactions between the Identity Provider, the user, and the Relying Party, the best place to look is in the CardSpace Technical Reference and the Integration Guide (see the “References” section).

The consumer value of information cards is blindingly obvious, but where do they fit in the enterprise space? Does “user-centric” identity have a place in the enterprise?

Within corporations, the success of a particular technology depends on how well it meets business needs. Some of the business needs du jour are regulatory compliance, security, and business process efficiency. CardSpace and the Metasystem have a strong part to play in this world above and beyond the simple fact that almost all enterprises have relationships with consumers and small businesses.

Historically, most applications have been built as stove-pipe solutions with their own methods of authentication and authorization. The result has been a mess, and companies have spent a small fortune on Single Sign-On (SSO) solutions just so that their users can log on once and not have to use a separate username and password for every line-of-business application.

When companies get beyond the issues of SSO, they can look at how they might integrate internal applications to enable new interaction channels adding additional business value. For example, they can composite applications made up of components from existing applications and combined with new business logic.

They also consider how they might integrate with external organizations using federation. Examples here include business partners accessing enterprise applications, employees using Application Service Providers (ASPs), and portals integrating with third-party services.

This thinking has led to an upsurge in service-based architectures and is quite possibly the reason many are reading this book! At a time when people are turning to services to solve their integration issues, it is natural to think of identity as a service. An identity service layer, integrating with other identity service layers, makes a lot of sense! The technologies that enable this are WS-Trust and the Security Token Service.

Figure 8.17 is the classic Identity Metasystem “triangle” of trust. This can scale easily because the user is at the center and the Relying Party and Identity Provider are loosely coupled. The RP could be just one website or hundreds of sites and services. Trust is mutual between all parties in the Metasystem, not just the IP and RP. The underlying protocols have the advantage of being very simple and flexible and the whole architecture is easily managed and scales well.

Figure 8.17. The Identity Metasystem “Triangle of Trust.”

Identity in the enterprise follows a far more rigid model: the domain model (Figure 8.18). The Identity Provider, the domain controller, creates the users and services (security principals) and makes all the trust decisions for everyone. This is a world of absolute authority and sharply defined lines of trust: a world where the user—and the business unit—are disenfranchised.

Figure 8.18. Domain model trust: a totalitarian regime.

Federation is a set of agreements, standards, and technologies that enables one to make identity and entitlements portable across autonomous security domains. A lot of value can be derived by federating the domain model. For example, if one is using Active Directory, one can extend it using Active Directory Federation Services (ADFS) and the WS-Federation Passive Requestor Profile protocol. This enables one to have web SSO with one’s business partners but it does not support active clients. In other words, it allows federated browser applications but not web services applications.

The problem is that the simplistic domain model makes the job of controlling access to resources inefficient and unreliable (and therefore unsafe). As the domain model is federated outwards via acquisitions and partnerships, one ends up with a mesh of many, many enterprise domains, each stuck with a central IP making all the decisions. One can try building circles of trust, but ultimately one ends up with a complex and difficult-to-manage mishmash of policy.

The key is to realize that it is the owner of a resource that should be making the trust decisions, not centralized IT. It is a business decision, not an IT decision (although they should still have a say). In other words, the Relying Party should control access to its resource(s), not the Identity Provider.

This is an age in which IT departments are devolving power to end users to reduce support costs—for example, allowing users to manage their own PCs and controlling network access through policy enforcement. Why not allow the owners of a resource—that is, the business unit or individual—decide who should have access while under the aegis of enterprise policy? Why not let the employee agree to privacy and consent policies during the federation process?

CardSpace offers many things to the enterprise: a standardized and ubiquitous means of providing credentials, flexible user-driven relationships, multiple user roles, antiphishing features, multifactor authentication, information minimalization, active federation and, not least, easy implementation. But perhaps the greatest gift is the ability to devolve access control to the true resource owners. And the way it does this is via security token services.

In Figure 8.19, there are two enterprises: Contoso and Fabrikam. Contoso is a Microsoft shop using Active Directory; Fabrikam prefers to use Linux-based servers. Two business groups, C from Contoso and F from Fabrikam, meet up and strike a deal where members of C can access one of F’s services. They agree to a set of claims that will be exposed and F modifies the policy of the resource STS to authorize the C group; that is, a trust relationship is set up.

Figure 8.19. Federation using Security Token Services.

Lisa, who works in C group, has been sent an email describing the deal. Sure enough in her WCF client application there is a new option to use the F service. When she selects the option, WCF accesses the F service policy (step 1) and gets redirected to the resource STS, which passes back its policy (step 2). WCF sees that the <issuer> element is empty so it launches CardSpace (step 3). The only Information Card that is lit up is her employee card because that is the card with an IP that can provide a SAML token (say) and the Employer and Group claims. In any case, she knows she has to select her company information card—it is her online employee badge.

When Lisa chooses her employee card, an RST containing her Kerberos credentials and F’s STS policy are sent to the Contoso Active Directory STS (step 4). It authenticates her and sends an RSTR containing a signed SAML token (step 5). Lisa confirms the release of the token and an RST is sent on to the Fabrikam resource STS (step 6). The token is validated—the signature proves it comes from Contoso—and the group claim (which has been transformed to the department claim) shows that Lisa works for C. This matches the policy, so the STS issues a Fabrikam token (step 7), which happens to be a special token format that only Fabrikam applications use and understand. WCF presents this to F group’s application (step 8), and the application gives back to Lisa exactly the information she needed to do her job.

Clearly this model is extremely powerful and encompasses many interesting scenarios, such as mergers and acquisitions. STSs are destined to become the cornerstones of IT infrastructure—they are the identity layer. This is why many companies are anxious for the release of AD/STS and other STS solutions, and the vendors are anxious to get their STS products to market.

Ultimately, the interesting question here is not “Where do information cards fit in enterprise scenarios?” but rather “Where does the domain model fit?” If information cards become increasingly ubiquitous for both consumers on the Web and for employees using federated business applications, is it desirable to maintain two enterprise architectures? Companies are already moving toward security “de-perimeterization.” Will they move to one unified identity architecture? Only time will tell.

In any case, anyone using WCF is in good shape. It’s a simple change of client credential type from Windows to IssuedToken and a different token handler.

Windows CardSpace and the Identity Metasystem provide users with a simple, consistent, and secure way to handle their online identities. They no longer have to remember usernames and passwords, and are protected against phishing attacks. Built-in support for additional authentication factors such as smart cards allows banks and others to improve levels of security while providing a consistent and familiar user experience.

Information cards can be used with both websites and web services. The protocols are simple and open, allowing them to be used in a broad range of contexts with different vendor offerings to choose from.

Very little developer effort is required—but to truly believe that, one needs to take a look at the next chapter...