Infocard: on Cards & Tokens

Well, I knew that. This is a question that, unspoken or explicit, often arose every time I introduced somebody to Infocard (and between enterprise engagements, Mix,

regional events, webcasts, colleagues & relatives that actually happened quite a lot of times by now :)). And the question is:

 

“When I authenticate with a website using Infocard, to whom I send the card?”

 

When you hear this, it’s usually the case to make few steps behind and consider the larger picture (BTW, the card itself NEVER gets sent).

The card metaphor may induce to think along the lines of the question above. After all, what happens on a typical real life situation in which you use a card? The police officer stops you because you were speeding (last week I got my first ticket in the US! Yeeeah), you show him your driver license and the car registration (and try to answer when he asks you “what this WS-STAR plate is supposed to mean?”). You land in some airport abroad, the custom officer check out your passport. You’re the subject, the officer is the relying party (RP),  the government is the identity provider (IP), the passport is the card. Smooth, huh? Well, this is ALMOST it. You carry around a passport because it would be very impractical to call your embassy and have them vouch for you every time you need to prove your nationality. Instead, your government writes down your nationality in a piece of paper that is VERY difficult to reproduce, and binds those data to yourself by including your picture (again, in a way that is difficult to subsittute). Insodoing, you can exhibit the piece of paper and be recognized by who has trust in your government and the robustness of the anti-fake technique used. That may seem straightforward, but it’s not: especially the part about trusting the robustness of the system. My passport was issued in a period during which the Italian government limited its validity to a 5 years timeframe, with the chance of renewing it for other 5 years. The renewal process, however, is just a stamp and it does not change the machine readable parts: so if an officer trusts only the output of a machine read, he will think that my passport is expired even it’s still valid! Of course, the frequency of those events is so low and the impracticality of calling the embassy every time is so high that the “piece of paper” technique is still the most convenient route. But imagine for a second! Imagine carrying around blank passport, with all the fields (Name, surname, nationality, expiration…) empty; while standing in front of the officer, you just rub your thumb on a corner of the passport et voila’! Automagically, your passport sends your thumbprint to your government and almost instantaneously a leafllet materializes between its pages, with the blank fields filled with the right, up-to-date information and a big authenticity stamp on it. You handle the leaflet to the officer and you’re happily done. How is it better than the traditional passport? TO begin with, if you drop it NOBODY but yourself (as the proud owner of your thumbprint) can use it for passing controls. Then, it never expires: when you materialize the leaflet you use it right away, so the leaflet validity can be extremely short (so that if somebody steals the leaflet itself, it has practically no time to use it). Furthermore, the info is always up to date: did u move recently? No problem: the government knows your new address and will use it on the leaflet, no need to rebuild the entire passport. The analogy is not complete (there’s no counterpart for the session key, more about it later), but you get the idea: if everytime I need an info owned by the governemnt I can obtain it quicky and at no cost by asking directly to the government itself, it makes no sense carrying around a precompiled passport.

Now: if in the traditional scenario it may seem absurd to call your consulate everytime you need to show a document,in the digital realm things go in a different way: everybody is pretty much at one web service call away! So there’s no need for the long term commitment of a 10-years passport, you can happily get your data and a stamp on it every time you need to. Managed cards work exactly like that. A card contains the instructions on how to contact an Identity Provider, and what kind of info can that specific provider certify about us; every time we select that card, we’ll somehow use it to obtain out magic leaflet. It is that leaflet that we will hand to the website, the card never leaves our machine. Now that we have an idea of how it works, let’s get down to the technical details of how it works.    

 

You give a thing to me, I’ll give a thing to you

 

In the world of web services, security information are carried around in what we call Tokens. A token is an XML element, described in fine details by the WS-Security specification, which carries claims (statements about something, like the fact that your email is “parapa@contoso.com” or that you belong to the Administrators group) and cryptographic material, that’s to say keys (or reference to keys which live elsewhere). A token is usually signed with the private key of the entity who produced (issued) it, so that 1) it cannot be modified without invalidating the signature 2) everybody who know the public key of the issuer knows for sure that this token truly comes from the issuer (as the only owner of the corresponding private key).

A token is a very useful thing! For a start: if somebody trusts the entity who issued the token, it will regard as truthful the claim it contains. The signature guarantees for that. Secondly, the key contained in the token can be used for performing interesting tricks such as encrypting and/or signing stuff (namely, other XML elements). Now: the token is a very generic structure, and it is usually created from existing cryptographic material of some kind. So the tokens come in different kinds, depending on the tipe of the original cryptographic material: X509 tokens, Username tokens, Kerberos tokens, SAML tokens are few that you may have heard of. Some of those tokens are created right away, from the originam material: if you have an X509 certificate, you can obtain a WS-Security token from it right away. Some other token are usually issued, like the SAML ones: that is to say, you ask some entity to issue a token for you. Turns out that this is such an important operation that the messages for requesting and receiving a token deserved a name (Request Security Token, RST, and Request Security Token Response, RSTR) and were standardized in another specification, WS-Trust. A web service that is capable of understanding RSTs and of emitting RSTR is called Security Token Service, or STS.

Issuing a token is a big commitment for an STS: the tokens bearing its signature are solid currency in the credibility domain, and in the wrong hands they may bring down the reputation of the entire system. What would happen if you could call the government, faking my voice, and obtain a leaflet with MY data with which you’d go through a passport control? The system would not be in business for long. When an STS emits a token, it better be pretty damn sure it’s issuing it to the right person. For verifying

if the requestor is really who is claiming to be, the STS does like everybody else: it asks the requestor to present proper credentials by using a security token. Example: you need to call a certain web service, that won’t talk to you unless you call it using a SAML token 1) signed by the IP X and 2) containing a claim about your age. Fortunately you are a customer of the IP X, so you can sent to it an RST for obtaining the desired SAML token; but for proving to the STS of X that you are really who you are, you secure (sing &/or encrypt) the RST using an X509 token (for example by inserting a smartcard). The STS verifies the use of your X509 on the RST, sees that it’s really your smartcard and decides to trust you: then it emits the desired SAML for you. What happened here? You exchanged a token with another: the STS has a policy which determines which tokens can be accepted as a proof of your identity, and for obtaining what you want (the issuing of a SAML token with your age in it) you have to comply with such a policy.

We are finally to the point in which we can connect all of the above with Infocard. A provider card is simply a “reminder” of the details of the services offered by a certain identity provider: the kind of token you can request, the set of claims that can be embedded in such a token, the address in which the STS is listening to RSTs, and the kind of authentication (=token) that the STS demands before performing its services. When we we browse an Infocard enabled website, in some way the website let us know that for authenticating we need to come back with a certain set of claims, packed in a certain kind of token, issued by a certain STS. Before showing up, the Infocard UI goes through our cards collection and select the ones which can satisfy the requirements. Once the user picks up a card, the system checks what is the preferred authentication method and prompts the user accordingly: if it’s username & password it will prompt for it, if it’s smartcard it will ask the user to insert one, and so on. They system will then create an RST, secured by the token we chose, and will send it to the STS. The STS will send back a RSTR containing the token we need. THAT token is the thing that will be sent to the website: the card was merely the mean though which we obtained it.

 

Wait a minute; wasn’t this thing supposed to get rid of passwords?

 

That’s another reaction that is pretty typical when we talk about provider cards and the authentication with the STS comes in the discussion.

Let’s think for a moment to the self issued cards, that we happily ignored in the above discussion. Self issued cards are in principle the same as managed cards: the main differences are 1) the STS which issues the associated tokens lives on board of the client machine itself, as part of the Infocard infrastructure and 2) you can choose the claims only from a predefined set of about 10 types. The fact that the STS lives on the local machine has 2 effects: a) the values of the claims are stored locally, so they *seem* inside the card itself b) the sheer fact of working in an interactive Windows session implies that you logged in the system with your credentials, so the local STS consider you authenticated just by the fact that you are sitting in front of the PC. IN THIS CASE, then, you don’t need passwords; or better, you need only one (your Windows password) for accessing all your selfissued cards (the optional PIN is a notable exception).

In the managed provider case, the remote STS has still the need to make sure it is really you before issuing the token with the claims you are asking: so we are back with the standard arsenal of authentication factors (something you know and/or something you have), with a couple of aces in the sleeve. The password is only one of the machanisms you can use for gaining the trust of the STS: Infocard offers you also X509 (locally resident or on smartcard), kerberos and… a token obtained by using another card 🙂 More on this on later posts, if you read until here you’re already a hero 🙂 I hope I managed to make things clearer, feel free to comment/ask clarifying questions!