Difference between revisions of "InfoCard"

Revision as of 18:03, 1 September 2022

Full Title

Step-by-Step Guide to InfoCard by Keith Brown MSDN Magazine (2005-04 & -05) taken from Microsoft website 2019-10-07

Code download is no longer available.

Contents of first Article - A first look

The Web can be annoying at times. I'm certain that I'm not alone in my frustration with filling out the same old forms on every Web site I visit. Like most other techies, I've acquired many tools over the years to help combat this repetition, and I even wrote my own password manager for my hundreds of different identities on the Web. To me this constant repetition is simply an annoyance, but to someone like my mom, it can be very confusing, and often confusion can lead to security vulnerabilities, such as using the same password everywhere.

Not only is this forced fragmentation of identity on the Web annoying, it's also really limiting the Web's potential. In this column, I'll introduce you to a system that I truly hope will be a uniting force for identity on the Web. It's called InfoCard, and it's planned to be available with Windows Vista™.

I am going to talk about InfoCard purely in the domain of Web services, because that's the only place you can use the prerelease bits as I write this column (see Microsoft Federated Identity and Access Resource Kit for Sept 2005 Community Technology Preview). But in the future it will also work with browser-centric Web apps. I've used Thawte and eBay as concrete examples because they're familiar. These examples are entirely fictitious—whether or not Thawte or eBay decides to implement InfoCard is entirely up to them.

What is Identity?

What is identity, anyway? The technical implications of this question are vast (never mind the philosophical implications). How should people be identified on the Web? How should entities such as services, companies, organizations, and the like be identified?

Take me, for example. My name is Keith Brown. I live in a suburb of Denver, and you can contact me via my Web site. I like rock music, vert skating, and Go. And I'm willing to share many of these details with Web sites that I trust, if I feel there's some benefit. These are all things that I can say about myself. But other people have things to say about me as well.

On eBay, I have a stellar reputation as a buyer and a seller. On Slashdot, my posts have been ranked "insightful," and I'm an upstanding member of a number of other communities. These reputations have value, but today they are stuck in silos. When I join a new community, there's no way to prove to people that I'll be an honest, intelligent, easygoing member. I have to start from scratch at every site, because there's no common way to share my eBay or Slashdot identity (with all the reputation I've worked hard to build). Sure, I can say, "I'm Keith over on eBay," but who is going to believe me?

I've made a bunch of statements about who I am. Do you believe them? Are they assertions of fact or merely claims? That really depends on who is making the statements and how much you trust that person or organization. For example, if you wanted to trade with me on eBay, you could easily discover that eBay says I have an excellent record for paying quickly. If you regularly trade on eBay, you probably have a reasonable degree of trust in their feedback system, so this is a claim you'll accept.

One approach that InfoCard takes is that it doesn't make any assumptions about the veracity of statements made about a given identity. It's up to you to decide whether you believe the claims I've made about myself, or the claims eBay makes about me. Thus the use of the word, "claim" as opposed to something stronger, like "assertion."

In fact, this leads directly to a definition of identity from the InfoCard perspective: A digital identity is a set of claims made by one digital subject about itself or another digital subject. This definition was proposed by Kim Cameron on his identity blog (www.identityblog.com). Kim is an architect at Microsoft working on InfoCard, and he's made many important contributions to the current thinking on identity.

Oh, and one more thing, in case you think you know where I'm going. The problem of having hundreds of identities today is not solved by merging them into a single identity that's used everywhere. That would introduce more problems than it solves. InfoCard allows you to have as many identities as you need. Looking into the future, you might have one identity that's issued by your government, one that's issued by your bank, and one issued by a Web community of which you're a long-standing member with a good reputation. You will likely have several self-issued identities, a few of which contain false information! I don't know about you, but I usually lie when a Web site asks me for personal information that I don't want them to have. I really don't live at 1313 Mockingbird Lane, Anytown, USA. But it satisfies the Web site and reduces my risk. InfoCard won't change your ability to do this.

The Spirit of InfoCard

Kim Cameron has postulated that there must be a set of objective laws that govern whether any given identity system will succeed or fail in a given context. No matter how an organization positions an identity system, if it breaks these laws, it will very likely fail in some way. Perhaps the failure will be a breach of security, allowing such mischief as identity theft. Or maybe people will simply reject the system because they don't feel comfortable with it. Regardless of the reasons, the InfoCard architects don't think they will succeed without adhering closely to these laws.

Seven Laws of Successful Identity Systems

The following laws are shaping the design and implementation of InfoCard. The architects of InfoCard simply don't believe that a system that ignores any of these laws could survive.

1. User Control and Consent The user should be in control of her information. She must be able to decide which bits of information to reveal to another party.

2. Minimal Disclosure No system that asks you for personal information is 100 percent secure, so the more you disclose, the more you expose yourself to identity theft and other attacks. Stable identity systems don't disclose more information than necessary in a given context, and they use identifiers that are designed specifically for the context. Let's say the context is you checking out a book at your local library. You shouldn't have to present your Social Security number, when the library can simply issue you its own unique identifier.

3. Justifiable Parties When applying for social services, it makes sense for me to present a government-issued ID card. But when I gamble online, I'm going to use a different identity. All parties involved must have a justifiable reason for being a part of the transaction. While it might make sense to use a Microsoft Passport when downloading MSDN® subscription content, I'd rather not use it for my PayPal account.

4. Directed Identity I value my privacy. I don't broadcast it for everyone to see. However, there are many public entities that need to be easily discoverable and therefore prefer to act like beacons. Amazon.com is a beacon. It broadcasts its identity to the world via its SSL certificate. But when I shop at amazon.com, I expect them to use a private identifier to track my activity at their site. Stable identity systems must support both omnidirectional identity (beacons like amazon.com) and unidirectional identity (my private relationship with amazon.com).

5. Pluralism of Operators and Technologies No single identity system is going to suffice in all contexts, and no single identity provider is going to be justifiable in all contexts. In order to succeed, the system must make it possible for many identity providers and technologies to work together seamlessly. No single identity system will rule them all, but there can be a system of systems (a metasystem) that presents a unified abstraction to users.

6. Human Integration The end user must be considered the endpoint of the authentication protocol. As an industry, we've done a fantastic job securing messages that travel over copper wires for thousands of miles. It's the last couple of feet between the computer console and the human where most bad things happen. Phishing and other social engineering attacks exploit the vulnerable user interfaces in use today. A stable identity system mitigates these threats to the greatest possible extent.

7. Consistent Experience A stable identity system presents an easy-to-understand abstraction to the user that is consistent no matter what underlying technology or identity provider is involved. The user must be able to select the most appropriate identity for a given context, and it should feel real. Digital identity shouldn't be an abstract thing to the user. It should feel as concrete as a library card in your pocket.

So to get a feel for the environment in which InfoCard has been incubating, let me take you on a brief tour of the seven laws. I have abbreviated them in my own words in the sidebar "Seven Laws of Successful Identity Systems," but you can take a look at the complete text at The Laws of Identity.

InfoCard: An Identity Metasystem

InfoCard encompasses a lot of different tasks. It orchestrates a few of the WS-* protocols to make the secure interchange of identity information feasible. It also presents a GUI that allows a user to choose among several digital identities, each of which is represented visually as a card. Figure 1 shows a very early "wire frame" UI. I'll talk a bit more about some of the other things it does later on, but first let me introduce the three players that are always involved in any InfoCard transaction.

Figure 1 Digital Identity Made Concrete for Users

First is the subject. An example of a subject is a user who wants to represent herself digitally on the Internet. Second is the identity provider (IP), an organization that issues digital identities. A close analogy is a company like Thawte, the issuer of the secure sockets layer (SSL) certificate that I use to identify my company's Web site. Finally, there's the relying party (RP), which relies on digital identity for its operation. Most Web sites and Web services today allow users to submit some form of identity, anything from a simple e-mail address to a digital certificate or something more exotic.

In accordance with the fifth law of successful identity systems, InfoCard is a metasystem that establishes a few guidelines and protocols to make it possible for many different identity systems to play nicely together. Lots of people have been thinking about digital identity for quite some time, and lots of different techniques have emerged. LID, SXIP, Liberty Alliance, and Microsoft® Passport are just a few examples.

Establishing Digital Identity with InfoCard

At this point I'm going to introduce a concrete example that I can build on throughout the column. Imagine that Thawte has decided to become an identity provider for InfoCard. I visit the Web site at Thawte and use a Web Form over HTTPS to set up a digital identity that they will manage for me. I might provide an e-mail address, home phone number, snail mail address, and so on. In fact, I might even set up a few different identities that I could use in different contexts.

Depending on the type of identity I want to establish and the amount of money I'm willing to pay for their service, Thawte may authenticate me before issuing an identity. Authentication could be as simple as verifying my e-mail address, or as sophisticated as calling around to verify every detail of my identity.

For each of these identities, Thawte will send me an InfoCard, an XML document that acts as a reference to the particular digital identity I just established. How they send it to me isn't dictated by InfoCard; they could e-mail it or I could download it from their Web site. Once I receive the InfoCard, I import it onto any computers from which I want to use it. Note that the InfoCard itself doesn't actually contain any of my identity details. That phone number I gave to Thawte isn't in the InfoCard.

What the InfoCard does carry is metadata that describes the shape of the identity. This information includes what claims it has inside it, such as an e-mail address, a home phone, and so forth, and what identity technology it uses such as Security Assertion Markup Language 1.1 (SAML). It also includes who issued it (Thawte), and a unique identifier that Thawte can use to look up my identity and get the values of each of the claims. So while my actual digital identities are safely tucked away on a highly secure server at Thawte, the InfoCards I've imported onto my computer are really just a way to remember that I have those identities. An InfoCard gives you the means to use and manage a digital identity.

My corporate Web site uses Active Directory® Federation Services (ADFS) to act as an identity provider. I can sign up for another identity there. The Web site authenticates me using Kerberos and issues an InfoCard that I can use to access my corporate identity for use with partners on the Internet. I import this card onto my computer. Once I've got some cards, I can use them as long as they are valid. The Thawte identity might be valid for a year (or however long I want to pay to maintain it), and my corporate identity is valid as long as I'm employed there.

Message Flow

In order to get a feel for how an InfoCard transaction works, I'm going to walk through an example to show the flow of messages between the players. For now, I'm going to ignore an awful lot of details such as how messages are secured, which protocols are used, and so on, to make sure the basic flow is clear.

Imagine that eBay has a Web service that supports InfoCard (the relying party). I launch my eBay auction manager application, a rich client app that helps me manage the multitude of items I'm auctioning on any given day. My app knows that it needs to present a digital identity to eBay in order to manage my auction items, but it has no idea which identity I want to use. So it first asks eBay what shape of credential it supports, what identity providers it trusts, and what types of claims it needs. eBay responds:

Credential type: SAML 1.1 or 2.0 Identity Providers: Entrust, Thawte, Verisign Requested Claims: email address

My app then takes this information from eBay and hands it off to the InfoCard system on my laptop. Up pops up a dialog that displays a list of cards that could satisfy eBay's needs. This includes all identities I've registered with Thawte that include e-mail addresses. It does not include my work identity because eBay didn't list my company as an identity provider that it trusts. In this dialog, eBay's logo is prominently displayed. Along with other countermeasures, this helps me verify that I'm not sending personal information to an imposter. Figure 1 should give you an idea of what this looks like. I click on the card that I use to sell items on eBay, and the InfoCard system makes a request to Thawte to get the one claim that eBay cares about: the e-mail address. Thawte returns a SAML token with this information.

InfoCard now pops up a view that shows me exactly what information I'm about to disclose to eBay, which is the e-mail address in the SAML token. I consent by pressing Submit, which allows InfoCard to pass the token to my application so it can fire it off to eBay and get started managing my auction items.

A lot happened here, but from my perspective as a user, I found that the interaction was straightforward. When my application connected to eBay, I was prompted to choose an identity to present, asked to confirm the personal information I was about to disclose, and then I was able to immediately start working with my auction items. And I didn't have to bother with a password. Under the covers, the strong crypto specified by InfoCard was at work ensuring the authenticity of the transaction.

The Laws Revisited

Consider this interaction in light of the laws of identity. The first law was satisfied: as the user, I was asked for consent, and shown exactly the information to be disclosed. I was also shown the logo of the relying party, so I could make an informed decision.

The second law was also satisfied. My home phone number and snail mail address were not sent to eBay, even though they were part of my digital identity maintained at Thawte. Only the information needed for that particular interaction was sent: the e-mail address. And really even that wasn't necessary; InfoCard is happy to craft a unique, opaque identifier that a relying party can use to identify you without having to know any personal information about you at all. This is called a Personal Private Identifier (PPID), and is computed as a function of the relying party's public key, the InfoCard id, and a random salt value. As a relying party, you can request a PPID if you want to track requests for someone without tying your tracking data to their personal information. This is a great way to protect the privacy of your users.

What about the third law? When I use a Web service at work, I use my corporate-issued identity. But I don't trust the sysadmins with my eBay identity. So I choose to use Thawte to manage my external identities. They have a lot more to lose if they misuse my identity and get caught doing it! There is a little circle of trust that comes together here: me, Thawte, and eBay. All parties to the transaction are justified in being there.

The fourth law also came into play. Anyone who uses InfoCard to talk to eBay sees eBay's logo. That's an omnidirectional identity, a beacon. But my relationship with eBay is private. The InfoCard system on my laptop isn't broadcasting my e-mail address via Bluetooth. Even if it wanted to reveal my e-mail address, it doesn't store that information, remember?

Because I was able to choose my own identity provider and identity technology, the fifth law was satisfied. Granted, the identity provider and relying party must support at least one technology in common for this to work, but InfoCard in no way limited which type of credential (SAML or otherwise) I used. The fifth law is really all about freedom of choice, and I'm happy to say that InfoCard buys into it.

The sixth law talks about securing the channel between the user interface and the user's brain. By using certificates with logotypes (RFC 3709), InfoCard avoids confusing the user by forcing them to look at certificates, and instead uses images that the user can recognize to identify the entities involved. There are other countermeasures that happen behind the scenes as well. For example, the entire InfoCard UI is actually hosted on a separate, more tightly secured desktop (similar to the one that WinLogon uses when you press Ctrl+Alt+Delete). Note that it's up to the identity provider to ensure that a bad guy doesn't register a certificate with a logo that looks like another company's logo. But that's exactly the sort of service that an identity provider supplies, and companies that participate will pay for that service.

Finally, the seventh law is satisfied by presenting the user with something that appears concrete: the cards themselves. And no matter what type of credential is used with the card, the user experience is the same. The user is shown a text representation of every claim that's going to be sent to the relying party, no matter what type of token or what type of claim it is. How can this be possible? InfoCard can't possibly predict all the types of credential formats that might spring up in the future. To solve this problem, the identity provider can include an optional "display token" that accompanies the real token. The display token contains a simple name-value collection that can be used to display the contents of the token to the user in text, even if InfoCard can't parse the actual token itself.

Sharing My Reputation

I hinted earlier that it would be really neat to have the choice of sharing my reputation from one community to another. If I could prove that I have a great reputation on eBay and Slashdot, I could use that as currency for other communities that I might want to join so I wouldn't have to start from scratch. And I might want to be known by the same handle at a few different online communities, so my friends know who I am in all those places. It would be up to me to make these linkages, but having that flexibility would be incredibly powerful.

This can happen under InfoCard. Say eBay decided to become not only a relying party, but an identity provider as well. In this case, I could get an InfoCard from eBay stating that I'm a reliable buyer and seller with 99.8 percent positive feedback. That's simply a claim that eBay is making about me, but remember the definition of identity: a digital identity is a set of claims made by one digital subject about itself or another digital subject.

Web communities that care about reputation might support eBay and Slashdot as trusted identity providers for these types of claims. I could now sign up for an account at one of these communities using my Thawte card, and then immediately bump up my reputation with my eBay card. I can show as many cards as I want to a community.

The downside to this is that the relying party can now correlate any identity information I give it, but it's ultimately my choice. If I trust the community and want to share more information with it, I can choose to do so. And a well-designed relying party will ask for the smallest possible amount of identifying information. I'd feel perfectly comfortable disclosing a PPID for my Thawte identity along with my eBay reputation. Even someone malicious couldn't do much with that!

Self-Issued Cards

A lot of the infrastructure I alluded to in my examples simply doesn't exist today. There aren't many identity providers out there that support InfoCard. The current version of ADFS doesn't yet support it either. So the InfoCard team has supplied a built-in provider that allows you to issue your own InfoCards to yourself to bootstrap things. In fact, the example cards shown in Figure 1 are actually self-issued cards.

To understand how this works, consider a traditional Web site that allows you to register with a user name and password. If that Web site accepted self-issued InfoCards, you could use a self-issued InfoCard to register. There would be no password; just select a card when prompted, and the Web site would record your PPID and make a note of the long-term key sent in the token. That key would replace the traditional password, and would be unique for every site you visit. Under the covers this key would be computed as a function of a master key, which would be generated randomly for each self-issued InfoCard, and the public key of the relying party. It would be as if you'd chosen a unique password for each Web site you visit, without actually going through the hassle of managing all those passwords yourself.

Self-issued cards are a great way to get started with InfoCard. If you have a Web service and want to make it a relying party, you can get a quick start by simply testing with self-issued cards. But in the long term, using a third-party identity provider will be much more powerful, because it enables user-constrained sharing of personal information between different systems on the Web.

Get Started Today

InfoCard is right around the corner, and it has incredible potential. On the social Web, it will pave the way for all kinds of new innovations by individuals and companies. For corporations, InfoCard will make it much simpler to connect with partners online. But InfoCard will only succeed if there are innovative people like you who are willing to take the time to build interesting relying parties and identity providers.

Subscribe to Andy Harjanto's blog (blogs.msdn.com/andyhar) if you're interested in experimenting with InfoCard today. Andy, a member of the InfoCard team, has provided links to specs and downloads (blogs.msdn.com/495649.aspx), as well as code samples for building relying parties and identity providers using Windows® Communication Foundation (WCF).

Contents of second Article

In my April 2006 column I began a discussion of InfoCard, the upcoming identity metasystem, which is being prepared for release in the Windows Vista™ timeframe. If you haven’t read that column, you should definitely start there because I’m going to assume you’re familiar with the basics I covered. This time around, I’ll go deeper into how the identity metasystem works, and write a service that relies on InfoCard for authentication.

A number of you sent me questions after reading the April column, so I’d like to clarify some things before drilling deeper. Technically, InfoCard is only one part of the identity metasystem: it’s the identity selector—the front-end GUI that’s displayed to the user. I tend to use the term InfoCard to refer to the metasystem as a whole simply because it’s a heck of a lot easier to say, and I think it sounds more concrete.

The identity selector being implemented by Microsoft will first surface in the Windows Vista operating system. If you saw any PDC 2005 talks, you most likely saw the identity selector in action. But InfoCard will be available on earlier versions of Windows® as well, including Windows XP. And Microsoft has made it clear that it wants to work with other operating system vendors to provide tips on designing secure identity selectors for their platforms as well. If InfoCard is to be successful, it needs to be very widely deployed, and not just on Microsoft® operating systems.

Some of you also asked for clarification about Security Assertion Markup Language (SAML), which is a standard that specifies the shape of a credential (or token, in WS-* terminology), as well as a protocol for passing these credentials around. InfoCard can use many types of tokens, including SAML tokens; self-issued cards happen to use SAML 1.1 tokens, for example. While SAML tokens are fairly common in InfoCard, WS-Trust is the protocol that is used to obtain and exchange tokens. The SAML protocol is not used by InfoCard.

What about folks using the Java language to build Web services? Back in August 2005, Ping Identity, a major player in the SAML space, released a Java toolkit for writing server-side applications that interact with InfoCard. It was released as a work in progress, but when it is finished, according to the toolkit documentation, it should be possible to build Web services (on top of Axis) and servlet-based Web applications that can request and handle all kinds of InfoCards from InfoCard-enabled clients.

And finally, InfoCard is not the "Son of Passport" that some in the media seem to fear. Passport is a single identity system and, as such, naturally fits into the metasystem as one of many technologies available to InfoCard users. But unlike the old days when Passport was being positioned as the only identity system you’d ever need on the Internet, today Microsoft is proposing a metasystem that allows the user to choose the identity technologies that make sense for her. Passport works well for accessing Microsoft properties like MSN®, but as an InfoCard user, that’s the only context in which I’ll be using Passport. My friends will tell you that I was never a big fan of Passport, but I am really excited about InfoCard, and you should be too!

InfoCard Interactions and Protocols

In the April column I talked about three InfoCard players—the subject, relying party, and identity provider. Most Web developers who need to add support for InfoCard to their Web services and applications will be acting as a relying party, so I’ll focus on that role here.

Figure 1 is an interaction diagram from "A Guide to Integrating with InfoCard," which used to be available on the Microsoft download center. It illustrates how a user can authenticate with a service using InfoCard. In the diagram, you can see the identity provider (the relying party), which is a Web service, and the subject, which is the user. The client app the user is running is also shown for clarity. Figure 1 InfoCard Interaction

The first thing to notice is that in order to use InfoCard the user must first enroll with an identity provider. That’s the out-of-band step shown by a dashed line in the figure. It could be as simple as creating a self-issued card on her own machine using the InfoCard GUI, in which case the identity provider is right on the user’s machine. Alternatively, the user might obtain an InfoCard from a standalone identity provider. A newly issued InfoCard is an XML document that can be transmitted to the user via e-mail, Web download, and so forth. There is no required protocol for how the identity provider authenticates the user or issues the InfoCard.

Once the user has one or more cards, the required protocols move into action. When the user runs an InfoCard-enabled application that makes a request of an InfoCard-enabled Web service, the first step is for the app to determine what type of identity and channel security the service requires. This is shown as the first round-trip to the service (Steps 2 and 3 in Figure 1). The protocol used here is WS-MetadataExchange, often referred to as WS-MEX, or just MEX.

The application now invokes the identity selector (Step 4), passing in the policy retrieved from the service. The identity selector pops up a secure GUI showing the user a collection of cards that would work for the given policy (Step 5). This is primarily governed by the type of token and the type of claims required by the service.

If the user has never used this service before, InfoCard will display the service’s and issuer’s certificate logos, giving the user a chance to visually verify that he’s talking to the right Web service so he doesn’t give away identity details to an imposter.

Once the user selects a card to send (Step 6), the identity selector initiates a behind-the-scenes conversation with the identity provider that issued the card. First there’s a MEX exchange (Steps 7 and 8), where the provider’s security policy is discovered so that the exchange can be properly secured. This also tells InfoCard how the user is supposed to prove his identity to the identity provider. For example, if the provider requires a password, the identity selector will prompt the user for his password. Now a WS-Trust request is sent to the identity provider (Step 9). This request includes the user’s proof, such as the password as in the example. It also includes the ID of the card, which allows the provider to figure out which account is being accessed. Also included is a list of requested claims—the identity details that the Web service wants.

Assuming the identity provider can validate the user’s password that was sent, it will now construct a security token for the user to send to the service. This token will contain all the claims the service requested. If the service requested the user’s street address, that address will be included in the token. Remember that the original list of cards shown to the user included only those that support the claims being requested. Note that a password is just one of several ways an identity provider can authenticate the user. Other techniques include using a certificate, Kerberos credentials, or a self-issued InfoCard.

WS-Trust is the core protocol around which InfoCard is built. It is basically a credential exchange (or more technically, a security token exchange) protocol, and is implemented by what is called a security token service (STS). The most common type of STS is an identity provider like the one shown in Figure 1. In Steps 9 and 10, the user’s password is being exchanged for a signed set of claims from the identity provider’s STS.

Now the identity provider signs and encrypts the token and sends it back to the InfoCard identity selector (Step 10) along with some key material that can be used by the client application to prove that it obtained a legitimate token from the identity provider. This key material is known as proof of possession.

When the identity selector receives the token and proof of possession, it decrypts the token and shows the user one final GUI. This allows the user to see exactly what identity data is going to be sent to the service. If the service requested the user’s street address, the actual street address will be displayed to the user. Figure 1 doesn’t show this particular interaction, but it’s an important one for the user. Once the user gives his final blessing by pressing Send, the identity selector returns to the application (finally!) giving it the token and proof of possession it needs to authenticate with the target service. As you can see, there’s a lot going on under the hood when you select an InfoCard. Fortunately, if you’re a client or service developer, you don’t have to worry about building any of this infrastructure.

At this point the application makes its request to the target service using WS-Security to send the token along with a signature formed via the proof-of-possession key material (Step 11). The user has now been authenticated and the service has the claims it requested and can use those claims to make authorization decisions and carry out the user’s requests.

It’s possible and even likely that WS-SecureConversation might be used at this point to set up an efficient secure channel for an ongoing conversation between the application and the service, but that’s beyond the scope of the InfoCard specification.

Considerations for Relying Parties

As a relying party, the first thing you’re going to need is a certificate to identify your organization. This is the beacon type identity that I discussed in my previous column. A large percentage of secure Web services today already use certificates to enable secure sockets layer (SSL), so this shouldn’t be a significant barrier to adoption of the technology.

What is a bit new is that this certificate needs a name that represents your organization, not your URL (as in an SSL certificate). It also should include logo images for both the issuer and subject, following the guidelines in RFC 3709. Each image isn’t physically embedded in the certificate; rather, it’s linked to avoid making certificates even bigger than they already are. The logotype extension includes a URL that points to an image on the Web. It also includes a cryptographic hash of that image. The hash is embedded in the certificate to allow the program displaying the logo to ensure that the image hasn’t been modified since the certificate was issued.

Another major consideration is the type of identity information (claims) you’ll request of your users. InfoCard has already defined several claim types that will cover the needs of most applications, but this list can be extended by third-party identity providers that serve other types of claims. The current list is shown in Figure 2. To form the full Uniform Resource Identifier (URI) for each claim, append its suffix to schemas.microsoft.com/ws/2005/05/identity/claims. You’ll see these URIs in policies exposed by InfoCard-enabled services. This is the way you specify the identity expectations your service places on its users.

Figure 2 Claim Types Defined by InfoCard Profile

Claim	URI Suffix
First name	givenname
Last name	surname
E-mail address	emailaddress
Street address	streetaddress
Locality name or city	locality
State or province	stateorprovince
Postal code	postalcode
Country	country
Primary/home telephone number	homephone
Secondary/work telephone number	otherphone
Mobile telephone number	mobilephone
Date of birth	dateofbirth
Gender	gender
Private personal identifier	privatepersonalidentifier

Many Web services don’t need any personally identifiable information at all, and you shouldn’t ask for anything you don’t absolutely need. With InfoCard, a great way to start is by simply identifying the user with a Private Personal Identifier (PPID). This is communicated as a base64-encoded byte array. In my own tests this value has been 32 bytes long, but its definition doesn’t include a length, so don’t rely on this. As an example, a self-issued InfoCard will generate a unique PPID for each target service based on the card’s unique ID, the service’s public key, and a random salt value. The PPID alone is not considered personally identifiable information, so it’s a great way to associate your own data with a user while preserving her anonymity. I’ll show an example shortly.

The Notepad Service

Microsoft support for InfoCard rests entirely within Windows Communication Foundation today. It is surprisingly easy to add InfoCard support to a Web service, making that service into a relying party. It’s really just about selecting the appropriate binding, and you can do it all with a configuration file if you want.

Figure 3 shows a Windows Communication Foundation Web service with a contract called INotepad. This allows a user to leave herself a note by sending the SetNote message, and lets her retrieve that note later via the GetNote message.

Figure 3 Notepad Service

The Contract

[ServiceContract] public interface INotepad { [OperationContract] string GetNote(); [OperationContract] void SetNote(string data); }

The Service Code

public class Notepad : INotepad { static object _lock = new object(); static string note = ""; public string GetNote() { lock (_lock) return note; } public void SetNote(string newNote) { lock (_lock) note = newNote; } } class Program { static void Main(string[] args) { try { ServiceHost sh = new ServiceHost(typeof(Notepad), new Uri("https://localhost:8080/notepadService")); sh.Open(); Console.WriteLine( "Listening. Press <enter> to quit the service."); Console.ReadLine(); sh.Close(); } catch (Exception x) { Console.WriteLine(x); } } }

The Configuration File

<configuration> <system.serviceModel> <services> <service type="InfoCardSample.Notepad"> <endpoint address="https://localhost:4123/notepadService" contract="InfoCardSample.INotepad" binding="wsHttpBinding" bindingConfiguration="myBinding"/> </service> </services> <bindings> <wsHttpBinding> <binding name="myBinding"/> </wsHttpBinding> </bindings> </system.serviceModel> </configuration>

Figure 4 shows the corresponding Windows Communication Foundation client code. Because the client dynamically discovers the service’s binding requirements via WS-MEX, there’s no need for a client-side configuration file in this app. If you build and run this code, you’ll quickly see a flaw in the design. It works fine as a scratchpad for a single user, but as soon as two or more users invoke the service, they begin stepping on each other’s notes. By adding InfoCard support, I’ll ensure that each user gets a personal storage area for notes that no other user can see. I’ll do this without requiring user registration or any personal information.

Figure 4 Client Code

using System; using System.ServiceModel; using System.ServiceModel.Design; using Microsoft.InfoCards; using InfoCardSample; class Client { static void Main(string[] args) { try { if (1 != args.Length) { Console.WriteLine("Usage: client \"string to send\""); return; } string url = "https://localhost:8080/notepadService/mex"; ChannelFactory<INotepad> factory = findService(url); INotepad chn = factory.CreateChannel(); displayNote(chn.GetNote(), "Old"); chn.SetNote(args[0]); string newNote = chn.GetNote(); displayNote(chn.GetNote(), "New"); // Clean up factory.Close(); // close the client’s channel } catch (Exception x) { Console.WriteLine(x); } } static ChannelFactory<INotepad> findService(string addr) { MetadataResolver mexProxy = new MetadataResolver( new EndpointAddress(addr)); foreach (ServiceEndpoint serviceEndpoint in mexProxy.RetrieveEndpoints()) { if (serviceEndpoint.Contract.Name.Equals( typeof(INotepad).Name)) { return new ChannelFactory<INotepad>( serviceEndpoint.Binding, serviceEndpoint.Address); } } throw new Exception( string.Format("Couldn’t find INotepad at address {0}", addr)); } private static void displayNote(string note, string desc) { Console.WriteLine("{0} note: {1}", desc, null == note ? "<<NULL>>" : note); } }

The majority of typing you’ll do will be in the service configuration file. You’ll need to tell Windows Communication Foundation where to find its certificate. You’ll also need to advertise what sort of security token you want from your clients and what claims you expect to see in that token. For this application, I allow my clients to remain anonymous, choosing to rely on a PPID claim. I let clients use the self-issued identity provider, which issues SAML tokens.

It may seem odd to authenticate clients that will remain anonymous, but it’s really no different than the way a typical bulletin board works today. When you create an account, you supply a user name and password. The user name is pretty meaningless; keith3425 doesn’t give the board a clue as to how to get in touch with me. But the password allows the site to ensure that it’s the same person logging in each time.

InfoCard makes this type of service very easy for users. There’s zero registration required; because PPIDs are unique for each site, the user can simply create a single card that she uses at all anonymous sites like this. She doesn’t have to go into that familiar loop of attempting user names until she finds one that hasn’t been used already. You can think of her user name as being replaced by a PPID, which is generated automatically by InfoCard. She also doesn’t have to generate and manage yet another password. A strong key will be generated dynamically to use with the service.

The biggest drawback to using self-issued tokens is that they can be a hassle if the user works on multiple machines. Eventually, a third-party identity provider will be able to centralize the user’s identity so that it can be used from any machine. In the future there may even be portable STS hardware devices that you can carry around and plug into your computer’s USB port. This would make self-issued cards more portable and secure.

InfoCard-Enabling the Notepad Service

Enough talk; let’s do it. The first step in InfoCard-enabling the service is to obtain and install a certificate. I’m going to use the one that came with the InfoCard Resource Kit that shipped back in September 2005. The logos in it are configured to point to GIF files in a virtual directory at localhost/ServiceModelSamples. I’ll supply a batch file to get the certificates and logos set up for you if you’re following along with the code sample.

Figure 5 shows the updated service configuration file. Note that the references to the Fabrikam certificate are required because it’s used to authenticate the service to the client application, allowing the client app and service to negotiate security for their communication channel. Also, it’s used to authenticate the service to the identity provider.

Figure 5 Updated Service Configuration File

<configuration> <system.serviceModel> <services> <service type="InfoCardSample.Notepad" behaviorConfiguration="MyServiceBehavior"> <endpoint address="https://localhost:4123/notepadService" contract="InfoCardSample.INotepad" binding="wsHttpBinding" bindingConfiguration="simpleInfoCardBinding"> <identity> <certificateReference findValue="Fabrikam" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName" /> </identity> </endpoint> </service> </services> <bindings> <wsHttpBinding> <binding name="simpleInfoCardBinding"> <security mode="Message"> <message clientCredentialType="InfoCard"/> </security> </binding> </wsHttpBinding> </bindings> <behaviors> <behavior name="MyServiceBehavior" returnUnknownExceptionsAsFaults="true" > <serviceCredentials> <serviceCertificate findValue="Fabrikam" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName" /> </serviceCredentials> </behavior> </behaviors> </system.serviceModel> </configuration>

Also note the binding’s security mode. I’m now specifying message-level security, which indicates the need for the WS-Security suite of protocols. The clientCredentialType is specified as InfoCard, which is really just shorthand for a self-issued SAML token that has no personally identifiable information in it, only a PPID. If you want to specify other claims, use the wsFederationBinding instead of wsHttpBinding; this allows you to specify the exact claim types you’re looking for.

Figure 6 shows the updated service code, with only the guts of the Notepad class that changed. You’ll see here that I’m now using a dictionary instead of a single string to store notes. The dictionary is keyed off the base64-encoded PPID. There’s really no reason to bother decoding the PPID into a byte array if a unique string is good enough to identify the user, so my dictionary uses a string PPID as its key.

Figure 6 Updated Service Code

const string CLAIMTYPE_PPID = "https://schemas.microsoft.com/ws/" + "2005/05/identity/claims:PrivatePersonalIdentifier"; static Dictionary<string, string> ppidToNotes = new Dictionary<string, string>(); string getCallerPPID() { AuthorizationContext ctx = OperationContext.Current.ServiceSecurityContext.AuthorizationContext; foreach (ClaimSet cs in ctx.ClaimSets) { foreach (Claim c in cs) { if (CLAIMTYPE_PPID == c.ClaimType) { return (string)c.Resource; } } } throw new Exception("Expected a PPID claim"); } public string GetNote() { string base64EncodedPPID = getCallerPPID(); lock (ppidToNotes) { if (ppidToNotes.ContainsKey(base64EncodedPPID)) return ppidToNotes[base64EncodedPPID]; else return null; // new users start with null note } } public void SetNote(string data) { lock (ppidToNotes) { string base64EncodedPPID = getCallerPPID(); ppidToNotes[base64EncodedPPID] = data; } }

Besides the synchronization code, the major new addition is the getCallerPPID function, which shows you how to use the new claims-based authorization feature in Windows Communication Foundation to discover the claims that were sent in the token. This code simply searches for a PPID claim. If there are other claims you requested, such as a user name or e-mail address, you can look for those as well using the URI for the claim types you are interested in.

The client code that looks up the service via WS-MEX also changed a bit. The MEX code doesn’t change, but once the channel factory is created, a behavior is dynamically added that tells the client-side Windows Communication Foundation plumbing to use InfoCard credentials with the service, as well as what certificate to expect for the service. This extra piece of code is here:

ChannelFactory<INotepad> factory = new ChannelFactory<INotepad>( serviceEndpoint.Binding, serviceEndpoint.Address); // indicate that we’re going to use InfoCard 
InfoCardClientCredentials creds = new InfoCardClientCredentials(); X509CertificateIdentity cid = (X509CertificateIdentity) serviceEndpoint.Address.Identity; 
creds.ServiceCertificate.Certificate = cid.Certificates[0]; factory.Description.Behaviors.Add((IChannelBehavior)creds); return factory;

If you build and run the new service, you’ll notice that on the very first call to the Web service, the identity selector pops up! Once you select a card and submit it, you’ll see the second GUI that shows the actual information that’s going to be sent; click the Information tab to see the personal information that will be sent. In this case, you will see an empty list since none of your personal information is requested. The PPID isn’t really personal information; it’s just an anonymous identifier that doesn’t mean anything to the user anyway, so it’s not shown here. After pressing the Send button, the rest of the client code runs, making a couple more calls to the Web service. You shouldn’t be prompted again while the client application is running though since the Windows Communication Foundation proxy is caching your credentials and doesn’t need to bug you anymore.

It’s pretty amazing to realize what you’re getting for about 10 lines of configuration code and maybe 20 lines of C#. You now have a login system that works over the Web with state-of-the-art authentication protocols. Windows Communication Foundation handles the heavy crypto required for authenticating the user’s credentials. There’s no worry about weak passwords, because you’re not relying on them! The user can create a single InfoCard that works at your site and at other sites; each site no longer needs to ask for a user name and password.

Exploring InfoCard Without WCF

You can play with InfoCard without using Windows Communication Foundation. Earlier I explained how the client application must invoke the InfoCard identity selector, handing it the server’s policy so the selector can display appropriate cards to the user. Well, if you’re using Windows Communication Foundation, the client-side plumbing handles this for you transparently. You don’t have to call InfoCard yourself, but you can if you want to.

If you look in the %WINDIR%\system32 directory, you’ll find a file called infocardapi.dll. A quick dump of its exports shows a function called GetToken. There’s also the managed assembly, Microsoft.Infocards.dll, which has a class called InfoCardClient with a static GetToken function that wraps the unmanaged version. You can build an array of policy elements and call this method directly if you want to pop up the identity selector and let the user choose a card. When the function returns, you’ll have the dereferenced InfoCard in your hands in the form of a security token, which is a great idea if you want to learn more about how the identity selector works.

If you want to simply pop the identity selector so the user can manage his cards, you can do this via the ManageInfoCard method. And if you want to import an InfoCard, you can do so by calling ImportInfoCard. There are no APIs for enumerating or otherwise programmatically manipulating InfoCards; you need to remember that this is something that the user must manage, since it’s his own personal information.

Oh, and one final note. If you’re wondering where the InfoCard identity selector itself lives, you can find it in a service called Microsoft Digital Identity Service. The code behind this service lives in a file called, appropriately enough, infocard.exe.

Winding Down

In this issue, I drilled deeper into InfoCard and showed the code for a relying party and a client. If it’s not already apparent, I’m really excited about the possibilities that InfoCard and the underlying identity metasystem present. Kim Cameron (the chief identity architect at Microsoft I told you about last time) has often said that if we can succeed in building an identity metasystem that respects the laws of identity, we will reach what he calls the "identity big bang," a new era of software which is identity-aware. I’m hopeful that InfoCard will help lead us there.

Send your questions and comments for Keith to briefs@microsoft.com.

Keith Brown is a cofounder of Pluralsight, a premier Microsoft .NET training provider. Keith is the author of Pluralsight’s Applied .NET Security course, as well as several books, including The .NET Developer’s Guide to Windows Security, which is available both in print and on the Web.

References