Federated Claims Based Authorization with your driver’s license

All the hip new Enterprise architectures feature phrases like “claims based distributed federated identity authorization and trust with single sign on” (or some permutation thereof) on their PowerPoint slides. If you find yourself firing up MSDN or Wikipedia to understand what any of this stuff means, you may be better off just looking in your wallet or purse first. For within, you carry everything you need to understand the concepts behind the techno speak. Just take a look at your driver’s license. The ways in which you use your drivers license in the real world is an analog (and precursor) to a lot of this technology. Old wine in new bottles.


Federated Identity Management

Consider what happens when you try to catch a flight at the airport.

To board a flight (access a service), you must pass an authorization check. FAA security policy mandates that you can board the aircraft only if you are a member of specific security group – the set of passengers who have purchased seats on the flight.

To perform the authorization check, the airport staff demands two security tokens from you:

  • Your identity token – your photo ID
  • Your boarding pass – or ticket.

Whoa dude, roar the security experts. But that photo ID is sooo easy to fake! Heck, did it themselves in their misspent youth – creating IDs issued to McLovin and using them to procure restricted beverages.

Fortunately, the airport chaps are security veterans, and don’t accept any old photo identity token. They only accept tokens issued by specific trusted identity management entities, such as:

  • The Dept. of Motor Vehicles of the 50 US states and territories – which issue driver’s license identity tokens.
  • The Governments of the world’s sovereign nations – which issue passport identity tokens

The agency that issues your identity token is a security token service (STS). Airport security trusts the STS because it knows (hopes) that the STS has worked hard to verify:

  • Your true identity – your name, your address, your weight (probably a lie)
  • Your membership in the trust domain the STS is responsible for, such as:
    • Residents of the State of Washington
    • Citizens of the United States

To coax a drivers license out of a trustworthy STS, you submit credentials issued by a trusted third party – your birth certificate, your social security card, your citizenship naturalization certificate.

Airport security accepts identity tokens issued by an entire planet’s worth of distributed security token services, each responsible for its own trust domain. This cross domain trust is called federation. When the airport federates with those trusted Motor Vehicle STSes, it becomes a relying party in the trust model. Which means that if you produce a driver’s license issued to Cosmo Kramer (or McLovin)- well, you must be Cosmo Kramer – cause it says so on the card, and airport security is relying on it. Welcome on board the flight!

Token Validation

Like all security tokens, your license has a Unique ID and an expiration date. The license also bears the signature of the issuer – WASHINGTON – and other marks that are hard to duplicate (for a while). Modern licenses also include a hologram or some device visible only under ultra-violet or black light. The issuer encloses the license in a tamper proof container and may include serial numbers and barcodes.

You’ve seen airport staff validate your license. They shine a black light source on it or peer at it closely with a magnifying eye piece. Beware, McLovin, for they mean business.

Claims & Assertions

Your drivers license contains several claims or assertions about you. These claims are made by the license issuer – the Dept. of Motor Vehicles. Your license contains several types of claims. For example:

Identity Assertion/Claims

  • Your name
  • Your picture
  • Your address
  • Your physical signature

Group Claims

  • Organ Donor

Other Claims

  • Your birthday
  • Your Sex
  • Height
  • Weight
  • Eye Color

Claims Based Authorization

To be allowed onto your flight, you must satisfy the FAA’s claims based authorization security policy.

Airport security enforces your access to the airplane, by executing claims based access check rules.

  • The first rule uses a sophisticated human vision algorithm & advanced biological neural nets to match the Photo identity claim on your license to your lovely face.
  • The second rule compares the Name identity claim on your license to the name printed on your boarding pass.

license.Claim[“Name”] == boardingPass.Name

If you don’t satisfy these rules, you shall not pass!

Pretty straightforward.

Federated Single Sign On

Your driver’s license is quite a remarkable security token. You can use the same driver’s license to board an airplane at any airport in the country!

The same security token even helps you to get that drink at the airport bar. The bartender, Stella, also uses claims based authorization to restrict access to her fine Guinness. The bar’s security policy dictates that you must be over 21 to be served. Therefore, Stella executes the following access check rule on the Birthday Claim in your license:

Years(Today’sDate – license.Claim[“Birthday”]) >= 21

And the wonders don’t cease. When you leave the airport, you find that you can use the same driver’s license to use another service – the rental car agency!

This magic is called single sign on. All you have to do is go to the local Motor Vehicle Bureau once, present your identity credentials and get your identity token. Armed with this one token, you can gain access to any service that federates with the State Motor Vehicle STS – i.e. accepts a driver’s license issued by the state. And each of these services can use the claims and assertions in your license to then enforce rule based access control and security policy.

Driver’s licenses are one of the real world’s means for delegated, distributed, federated claims based authorization and single sign on. With this concept well understood, you can now safely fire all your software engineers and replace them with the good folks from the Dept. of Motor Vehicles. Or at least be able read the literature on WS-Federation, SAML and related technologies without getting an immediate stroke.


How do you secure email? (Part Deux)

My last posting on securing email ended on a heart-stopping cliff-hanger, and I know the suspense has had you reaching for the soothing medication. But rest easy, dear reader, as our tale may now resume.

As you may recall, Toby and Violet’s plans to exchange secure email have run aground. Neither Toby nor Violet can figure out how to trust each other’s public keys. The security of secure email is built on the assumption that public keys are genuine – no trust, no secure email.

And so Violet and Toby do the simple thing. They meet at Tully’s for coffee and physically exchange public keys. Violet knows Toby’s public key is genuine because he gave it to her. She can safely verify his digital signatures and accept his email.

But what works for two doesn’t work for 637. For Toby wants to send secure email to 637 of his closest Facebook friends (the remaining 1039 worthy only of the Wall), many of whom aren’t even in the same city. Will Toby travel the world having coffee with each of his friends? Toby is eager to sip cappuccino in Florence and Lisbon, but his financial advisor (me) mandates otherwise.

Certificates of Authenticity

Toby recognizes that his public key needs a proper certificate of authenticity. Yes, sort of like the one that came with your prized William & Kate commemorative plate (I know you have one).

Toby heads to Certificates-R-Us, a well known Certificate Authority. Certificates-R-Us issues X509 Certificates – standardized digital packages that contain a public key, a statement about who the key belongs to, and evidence of the key’s authenticity.

Toby’s certificate acquisition process goes something like this:

  • Certificates-R-Us asks Toby for his papers. Toby produces his Government issued ID (Driver’s License) as evidence that he is the famed canine.
  • Certificates-R-Us has a higher bar for identity proofing than its competitor Certificate-Mart. It demands more information from Toby, such as his bank account or credit card number. Certificates-R-Us uses Toby’s personal information to conduct a series of validation checks:
    • It hires a credit agency to verify Toby’s identity by confirming his financial credentials.
    • It verifies Toby’s home address (taken from his license) by sending him snail mail
    • It calls Toby’s home phone number and listens to his melodious bark
  • Fortunately for Toby, his identity checks out.
  • Certificates-R-Us now proceeds with the certificate issuance:
    • It creates a new (public, private) key pair for Toby
    • It very carefully transfers the private key to Toby. Toby stores this key in a very secure store (Attila the Hound is always on the prowl, after all) and uses it to sign his email.
    • It issues a X509Certificate containing Toby’s public key and a statement that he is the Subject to whom the certificate was issued.
    • It collects processing fees from Toby (darn capitalism).


X509 Certificates in daa email

Toby signs his email to Violet with his spiffy new private key, then attaches his shiny new certificate to it. The certificate bears his name, and he is very proud of it. He also posts his X509 Certificate in a public directory to enable his many friends to download and use to encrypt the email they send him.

But how does any of this help? How does Violet know this isn’t another of Attila the Hound’s forgeries?

You guess rightly. Digital signatures to the rescue once again. What works for secure email, and documents, also works for certificates.

Certificates-R-Us signs Toby’s X509 Certificate with its own private key. The signature certifies the authenticity of Toby’s public key. Certificates-R-Us can confidently certify Toby’s public key because Certificates-R-Us created both Toby’s (public, private) key pair and the certificate.

And we’re done, right? Nope. I still have half my weekly quota of words to write.

To trust Toby’s certificate, Violet checks that the Subject of the certificate matches the sender (Toby’s) name. She validates the digital signature of the certificate issuer. She decrypts the signature with the issuer’s public key so that she can compare the issuer’s hash……and behold, we’re right back to where we started.

Because while verifying the issuer’s signature, Violet encounters yet another public key she cannot trust – the issuer’s !

Who do you trust?

In the real world, you trust someone because:

  • You chose to trust them explicitly
    • You know the person
    • The person has an honest face (more likely, good looking face – trust isn’t always rational)
    • You take their word for it (possibly because they honestly have a good looking face)
    • Etc .
  • You trust them because you explicitly trust somebody else who trusts them. Or attests to their trustworthiness. Or issues them a Photo ID. Or “likes” them on that website. Somebody vouches for somebody who vouches for somebody who vouches for…. This is called trust delegation.

You always end up trusting somebody explicitly. You can delegate and federate (and complicate) trust all day long – but in the end, that chain of delegation must end somewhere. The trust chain has to terminate at somebody you explicitly trust.

What is true in real life is also true for certificates. Toby’s certificate also has a certification path or trust chain.


Chains of Trust

Toby’s certificate issuer – Certificates-R-Us – also has a certificate; an intermediate or subordinate certificate issued by the well regarded Certificate Authority Woo Hoo Corp. This certificate contains – yes – the public key for Certificate-R-Us.


The Woo Hoo Corp Root Authority also has a certificate. This root certificate is special because no other authority certifies the public key the certificate contains. But since all X509 Certificates must be signed by someone, a root certificate is self-attested or self-signed. Woo Hoo Corp issues certificates to multiple subordinate Certificate Authorities – such as “Certificates-R-Us Asia” or “Certificates-For-The-Masses”.


How do you trust?

Violet can trust Toby’s certificate in 3 ways:

  • She can trust Toby’s certificate explicitly
  • She can trust the certificate for the authority that issued Toby’s certificate – Certificates-R-Us.
  • She can trust the certificate for the authority (Woo Hoo Corp) that issued the certificate for the authority (Certificates-R-Us) that issued Toby’s certificate (say that really quickly – thrice)

In the Direct Project parlance, Violet’s trusted certificates are her Trust Anchors. Violet picks the anchors she trusts, and stores them in her trust anchor store, or anchor list.

Your browser and your computer come pre-installed with the certificates of several highly trusted large Certificate Authorities, managed by vendors such as VeriSign. Every time you create an SSL connection to order your prescription from drugstore.com, your browser verifies the server’s identity, by going through a procedure very similar to Violet’s. There are a few other details involved, naturally, so how SSL works is best saved for another post.


Circles of Trust

The higher up the trust chain you decide to anchor your trust at, the wider the circle of trust you belong to. By trusting a Certificate Authority (CA), you make it simple for yourself to exchange secure email with an entire trust community – the community of individuals and organizations who hold certificates issued by the CA. The community admits only trusted parties– only those who meet the security and privacy policies outlined by the community members. The benefits of admission is an admission card – your X509 Certificate issued by the community’s Certificate Authority. Use the keys associated with member X509 Certificates to sign and encrypt email and have it accepted and trusted anywhere in the community.

You don’t have to pay Certificates-R-Us to set up a community or to issue certificates to your members – you can do it for free (now I have your attention – see below). Your community can set up its own Certificate Authority by running one of many commercial and open source certificate management servers. It doesn’t really matter as long as your community members install your CA certificate in their trust store.

The beauty and simplicity of this model is the powerful premise behind the Direct Project. Its not a new idea. We owe it to the geniuses who invented modern crypto & asymmetric encryption. And the designers of S/MIME.

Trusting a Certificate Authority has its costs. If you trust Certificates-R-Us, you trust any and all certificates issued by Certificates-R-Us – a possibly large community. If you trust Woo Hoo Corp, you trust half the planet. If you trust too broadly, you become too trusting. So trust wisely.

Creating your own Circle of Trust

To create a trust community, you must first create a Certificate Authority (public, private)key pair and X509 Certificate. You can then start issuing certificates (and keys) to your members. You can do this very cheaply by using the free tools: OpenSSL (open source) or MakeCert.exe (free in Windows).

Learn how to use makecert.exe using these sample batch files.

  • genca.bat: Create a new certificate authority certificate (root).
  • gencert_exchange.bat: Issue a new certificate to use for secure email – issued signed by the authority you created in genca.bat

You do need to be careful with the all the private keys you generate for your community members. After securely transfering them to the owning member using a secure out of band mechanism (such as password protected PFX files) – do ensure they are wiped from the machine you created them on. For Attila the Hound prowls endlessly.

You can find detailed documentation on makecert and PFX files MSDN and the Web.