From time to time it’s healthy to challenge the assumptions, and look at (allegedly) familiar things with new eyes. Few weeks ago I had to do just that with the idea of authentication: I wanted to shake a bit an audience of architects, and make them *think* about the problem instead of relying on the stereotypes they had about it. Judging from the evals I’ve got, it worked 🙂 if you want to give it a try, check in at the door what you already know on the subject and come to play!

 

The Tao of Authentication

authentic

being actually and exactly what is claimed

from M-W

 

When I say “authentication”, what do you think of? No, I don’t mean you identirati people, put your hands down; I mean what’s the intuitive idea in the collective imagery. The typical answer you get from a generic audience is something like “it’s when you check the identity of the user before giving access”. That sounds in line with what traditionally happens as of today, but we’ll see that there’s more than meet the eye.

Why do we authenticate, whatever that means? Simple. During the execution of the service we are offering we need the answer to some specific questions: the authentication phase is one of the ways in which we obtain the answer to those questions. Too abstract? Let me give you some notable examples.

Questions

Looks different from my usual messy sketches, eh? 🙂 Well, that’s a sample of my slides style. Some says they’re too busy, some likes them… pick your camp. But I digress.

Here we see our usual faceless clipart guy accessing a service (website or webservice, browser or smartclient, full fledged pc or mobile, doesn’t matter). The most common services I can think of would be web mail, blog engines, forums, perhaps instant messaging. What’s the real question we want to answer when we authenticate? Don’t take offense, but those services are not that interested in verifying that it is really YOU trying to access. They are rather interested in verifying that you are THE SAME RETURNING USER. You can sign up to web mail services & social networks with whatever name you like, in the end what will be verified is just that you own the same credentials that were established at signup time (this point is important, more on that later).

Returning users are not the only thing the service may want to authenticate. Let’s say you want to download DreamScene for your Vista Ultimate system; before giving you access, Windows Update will verify the authenticity of your installation via Windows Genuine Advantage (“is your system genuine?”). That’s true authentication, baby, and the outcome of the check will be exactly the same regardless of who the user is (your sister may be using her account on your PC: unsettling thought, I know).

The last question I want to consider for this scenario would be “are you affiliated with a partner of mine“? Again, I am not interested in verifying who you actually are: I just want to check that you belong to a category of users, then you can “inherit” the access level granted to the category itself. The canonical example of this is federation in all its forms, from classic passive B2B thru user-centered a’ la cardspace to OpenID. This question actually applies to any scenario, so I won’t repeat it (but we will explore it better later).

Alright, those were 3 questions in the “services” scenario. Let’s explore another case, perhaps as common as this one: access to content.

 

What’s content? Well, a lot of things. Online newspapers that charge you a fee for access (or that you can access online if you subscribed for the physical copy as well). Libraries like Safari. Picture & video sites of various kind (no need to actually go into details, right?).

If what I offer is premium content, the obvious question I’d ask would be: “did you pay?”. Again, who cares who you are; I just want to be sure I have your money in my vault already. That would probably fold back on verifying that you are a returning user, then retrieving some sort of “paid” bit associated to those credentials; i don’t want to get technical just yet.

The case of restricted content is actually more interesting. Imagine a website that gets its revenue stream from advertisement; imagine also that the kind of content cannot be shown to certain categories of users (younger than a certain age, coming from a certain country, etc). The website may set up a user authentication system for trying to keep the wrong users out, but that would not be going at the heart of the problem. The question in that case would be “Are you over 18 years old?” or “Are coming from Elbonia?”; that’s all the website needs to know for letting you in without getting sued. Setting up a user authentication system just for answering those questions means dramatically shrinking the number of ad impressions, to the point that it may not even be a viable business model.

Matchmaking websites face a similar problem: sometimes all they’d like to know is “are you married” and “are you of gender X”? For them it makes business sense to gather those info and “wake them up” at a succesful signin (you guessed, that’s the famous hostage identity), or at least it is sustainable (since revenues come from membership rather than pure ad impressions). Still, sometimes it may make sense to let people in not for membership but just for promotion. In Italy many disco clubs have evenings in which girls enter for free, while guys pay handsomely exactly because they know that the room will be filled with girls (that what they hope, actually, but don’t tell us :-)). An online counterpart of that model would make sense if you could answer the user “are you a girl” without imposing the “payment”/commitment of going through a signup/verification phase.

All interesting scenarios, but aren’t we overlooking one of the fattest cows in the online services? That’s right, I’m talking about the green (if you think in Euro that makes little sense, I know… I just adapted pretty fast).

Start handling money, and the required levels of security skyrocket all of a sudden.

The interesting thing about financial online services is that they often refer to some property or privilege you actually own in the offline world. Your mailbox or blog may not exist when you leave the kingdom of TCP/IP, but you bank account sure does. The questions you need to answer follow suit, and typically try to establish if you are the rightful owner/guardian of the resource you are trying to access/manipulate. When from your home banking app you want to list all the checking account movements in the last 90 days, the app needs to know the answer to “is this user the owner of this account?“. I can almost hear you: “hey Vittorio, but this is authoriZation!”. Right. But before you can make that authorization decision, you need to acquire that bit of information in a way that ensures you it is true. Does that sound like authentication now? You can acquire that information when you are provisioning the app account, or you can ask for it every time in form of claim (more about this later): sooner or later, that information needs to be verified and make its way into the system.

Besides the trivial home banking case, there are scenarios in which the money moved via online apps can be really massive. Imagine you are the admin that handles batch payments of the salaries of your medium-sized company; it’s FY end, and everybody get a raise (yeppa!). As you instruct the corporate banking app to change the payment size from the company’s account, what’s the question that the bank needs to answer before doing this? “Are you a legal representative of the company?” is one good one. Do I care if it’s YOU or your colleague, also from the admin department and entitled to do similar stuff? Nope. Do I care if this is coming from a prankster or disgruntled employee? You bet.

Let me give you a last scenario, before we leave financeland. Imagine a website that promotes financial tools like mortgages, lines of credit or similar. Many of the services offered would be subordinate to the answer “what is your credit score?” or, for my non-US readers, “are you known to be a good payer?“. Sure, name & other demographics may be a prized item for the service provider but the fact is that until you move to buy mode you don’t really need to know those.

Let’s examine a last set of scenarios, perhaps the most delicate: healthcare and eGovernment.

Now, those are IMHO the most serious scenarios: the questions they need to answer touch the most intimate sphere of our private business.

Let’s say you are a medical institution, and you make the result of xrays & blood exams available online. “are you the person that took this exam, or one of his caretakers?” is an extremely important yet delicate question. You simply cannot serve back results without a reliable answer to that question, and yet the act of gathering that answer must be secure, respectful of the privacy of the user and make all the necessary step for ensuring that the user knows what it is going on. All at the same time.

And what about any activity that requires some degree of government endorsement. Also in this case, who you are finally counts! And yet, today’s procedures may force the app to answer questions such as “what is the social security number of the user?” that is again an attribute, with all the issues that its gathering & authentication entails.

What we really do when we authenticate a user

We have seen that, from the business point of view, we often don’t give a damn about who the user really is; we just want the answer to some questions. And yet, the consolidate practice is actually authenticating a user (whatever that exactly means) and everything (sort of) works. How to reconcile this?

We can divide the questions we listed above into 2 broad categories:

A. Questions we can answer directly and by ourselves

B. Questions that “need investigation”

The category A is fairly atypical, since in extreme simplification it contains only one question: “are you the same user?“. I’ll extend this later, but for the time being humor me.

Here there’s the deal. When you create an account to some web mail site, you pick a user name and you tell the site: “dear site, here’s there’s my password: it will be our little (shared) secret. When you’ll see somebody giving you my username/password combination, you’ll know it’s me again”. When you send your username and your password one week later, the website can verify that they correspond to something in its archives and can answer YES to the question “is this a returning user?”.

The same happens when you use other methods of recognition. For a site that accepts personal cards, at signup time you’d say “dear site, here there’s a SAML token signed with my special private key for you: keep the corresponding public key somewhere (actually the UniqueID, but nevermind). When you’ll receive a fresh token signed with this key, you’ll know it’s me again”. When one week later you send a token from the same personal card, the website can verify that the signature has been performed with a private key corresponding to the public key stored in its archives and can answer YES to the question “is this a returning user?”.

You get the point. As a website I can use a trick, a mechanism for verifying by myself that the user is actually a returning user. The stuff that the user sends for doing his part of the trick is what I call credentials. I call the process of performing the trick verifying credentials (or checking credentials, or even authenticating credentials).

If my business needed to answer only the question “are you a returning user?“, credentials are all I need.

Category B. includes pretty much all the other questions you may think of. If I maintain a matchmaking website, and I want to know if you are married, I cannot pull a trick like the one I used with credentials: I need to really acquire the true answer somehow. But how? If I trust you, the user, then I may ask you and consider true whatever you tell me. That’s the approach that Live, Facebook, LinkedIn or any other “lightweight” service would pursue when they ask your name and your age. For a matchmaker, on the other hand, this is dangerous: if I combine a date between two member and one turns out to be married, the other one may sue. Not good. The obvious alternative is gathering the answer myself: I could organize an entry interview, verify all the questions I need (for example asking the candidate to bring a certificate of marital status) then save the results in a profile. I know there are other ways (who said claims and IPs back there?), but let’s say that this is the only way for the time being.

At this point we can again leverage the credentials trick, with an added twist. When we receive a set of credentials that actually correspond to something in our achieves, we can retrieve the profile of that user and use it for answering all the questions we will have. This implies another property of the credentials, or better of whatever we receive from the user: it must contain information for uniquely link the user with his profile in our archives.

Let me summarize at this point. What do we really do when we say that we authenticate a user in the classic meaning of the sentence? Three different things:

1. We answer the question “are you a returning user?” by verifying the credentials
2. We link the credentials to a profile in our archive
3. We “dehydrate” that profile, and we use it for answering our other questions

Let me stress why I include 3. in the discussion about authentication, despite its being pertinent to authorization. At the time of acquisition of the profile content, I did authenticate the information before accepting it; the fact that I am not repeating that authentication now is that it would not be practical, and I just trust that the info is still valid (and I may be wrong: one member could have interviewed in the morning and gotten married in the afternoon). As we’ll see later, there are architectures in which I acquire the information (and I authenticate it) at the same time of credential verification: at that point it will be clearer.

Let’s catch our breath a minute

Why am I doing all this? Authentication works that way, so what?

Well, I know that this stuff sounds trivial. And it is! But often people don’t spend much time really understanding allegedly trivial stuff, and the results is that after few modus ponens they get lost. Now we are totally on the same page, and we have a common terminology we can use for reasoning about all this.

If you compare the 3 things we do when authenticating user with the business scenarios we listed above, you’ll discover that there are cases in which the current system is definitely suboptimal.

For example: if I want to know if the user is older that 21, I don’t necessarily want to know if he is a returning user as well. And yet, with the solution shown above I still need to answer that question if I want to retrieve the correct profile. But from the business perspective I would be much better off if I could just answer the damn “are you >21?” question directly, and lose all the machinery above.

Another example: If the questions I need to answer must be as fresh as possible, for instance I need to make sure that you have an active credit line TODAY, NOW, the profile trick is ineffective. I need more agile ways of acquiring information, and again I may even not care about if the user is a returning one or not.

And a last, completely different example. Let’s say I offer a lightweight service on the internet, like a weather portal; I’d like to recognize returning users, so that I can customize the UI for them just a little. But at the same time, I am not protecting dark secrets not I am guarding anything of value. Why should I commit to put together and maintain a credentials verification system? All this create-secure-password-db-and-manage-cases-like-lost-passwords matter seems too costly to me, not worth the business advantages I’d get with customizability (note that my point here is not that cards would be easier, the point is: it not be worth to worry about authentication to begin with). Perhaps if could use a service that takes care of that for me…

You may have noticed I didn’t make mention of claims, identity providers, tokens… I am going to do it in part II of this post. We’ll see how those guys can help authenticating the answers to our questions in a much more natural way. But above all, I hope that framing the problem from the angle I provided here will give a rationale for the difference between credentials & identities, something that I am preaching since some time; and that it will help me to make the point that using an IP is NOT outsourcing authentication.