How often should you ask for a token?

On the Seattle-Paris flight. I’ve just posted the piece about validation-authentication-authorization, and i am a bit bothered by the fact that I was unable to delve into greater details for what concerns the authoriZation part. In particular, I’d like to address one of the misunderstandings which can derive from transporting verbatim the knowledge of Kerberos & “unattended” security in general to the world of user centered identity management. Some of you claimaniacs may find the stuff below pretty obvious: I do. But judging from some heated argument I had about this, it may turn out that it is not that obvious after all so it’s worth to write it down.

How often should your application ask for a token? It may seem a silly question, and you may be tempted to reply with the answer that my wife gets when she asks to her auntie how often she should turn the roast: “as often as needed”. Not the most actionable answer, I’m sure you’ll concur :-). As in good tradition, let’s take few steps back and look at the bigger picture.

When you sit at your workstation and log in your domain, if your local network uses kerberos you get your nice ticket granting ticket (TGT); from that moment on, every time you take a ride on your network carnival (access a share, a portal, a printer…) the network software takes care of using the TGT for getting a ticket for you, which is specialized for the resource you are accessing. Everything happens seamlessly, and the user is lulled in blissful ignorance of those frantic exchanges (that is, until you don’t stumble on a resource that you can’t access) thanks to the benevolent tyranny of the KDC on every account & resource in the domain.

Let’s now consider a web site. The user signs in through an entry point, where he is authenticated; but a successful authentication does not mean that from now on it’s a all-you-can-eat buffer, every single operation will still undergo authorization decisions before being performed. Maybe there’s premium content that is reserved to users who pay more; maybe you’re a reader role for a certain portal, which grant you readonly access but clicking on the “edit” links would result in access denied. In a traditional web site, those decisions would usually derive from the user information kept in the profile (the famous “answers” described in the Tao of authentication). By now we know that thanks to claims (&, by extension, tokens) the profile is no longer the only place we can turn to for answers, since we can obtain claims with just-in-time answers directly from trusted sources. However, that doesn’t mean that the strategy described for kerberos would be the best way of leveraging tokens in this case. The key point is that here we deal with an heterogeneous system, where different authorities come into play and boundaries have to be crossed: in this scenario obtaining a token means that the user is called to make an explicit decision and perform steps such as reviewing the info requested and authenticating with the IP of choice. In the example made in the former post, we required the signin token to contain both a http://…/PPID and http://…/age; however, it is possible that only http://…/PPID was strictly needed for a successful signin. The age claim may come into play at some later moment in the session lifecycle, for example when the subject attempts to access the trailer of a PG-13 movie. Does that mean that we should have just asked for PPID at signin, and that we should ask for a new token now? If you are used to non-interactive systems, such as backend 2 backed communications, you’d probably reply “yes”; however I would urge you not to underestimate the “interaction costs”. How likely is that during the session the user will attempt an access that entails an age verification? If the probability is high, one could say that the application needs the age info for working properly hence it makes sense to ask for it at signin time even if the actual authorization check will be performed at some later time. Besides minimizing costly cross boundary calls, this avoids to anesthetize the subject by asking too often its explicit consent and helps to understand what info the application works with; otherwise we risk training the user to click trough the process without paying attention.
This holds if we expect http://…/PPID and http://…/age from the same issuer, of course. If the former would come from a personal card and the latter from an IP, I would not advocate to force the user to pick all the tokens at signin time: besides leading to a confusing experience (I know others beg to differ here 😉 since we’re both guessing…), it would not optimize roundtrips and it may even not be compatible with some business model (if the IPs charge you for the tokens they issue, asking for more claims form the same issuer would save money; asking for more tokens upfront may result in charges that are not justified if you end up not ever performing the operation that would have required the extra tokens).

Bottom line: when the owner of the resources relies on information from external authorities for deciding if a subject should be granted access, it is a good idea to (whenever appropriate) consolidate the acquisition of those info in order to minimize cognitive overhead for the user & crossboundary authentications (while maintaining full user control, of course).

Once I decide ask those “extra claims” at sign in time, verifying their presence in the incoming token becomes responsibility of the authentication phase; the reason for which I require those claims, the fact that they will be later used for authorization purposes, does not change what I have to do for authenticating the token.

Alright, that takes care of the easy case: but what should we do when we do have to ask for a new token besides the sign in token, like when we need further assurances from a different IP? That would be out of the scope of this post, which would be satisfied from the mere recognition that we do have situations in which we have to do it. Anyway, I don’t think there can be hard & fast rules on how your app should metabolize the new claims; that would depend on the meaning that the operation has in the context of your application. If you are requesting assurance that the subject has enough money on his account for buying something, incorporating such a claim in the session may not be an especially intelligent idea: if you requested that info for authorizing a purchase, the amount in the account changed as a consequence of it and the claim “UserCanBuy$1000Item==true” may not hold anymore. If you are requesting to know if the user is not married, so that you can give write access to the personal ads, you can merge the new info with the claims you already received at signin time and be reasonably sure that the situation won’t change for the duration of the session. In any case, regardless of the transience of the claims, IMHO every incoming token should be processed through the validation-authentication-authorization with the same separation of concerns we pinpointed for the signin token, without succumbing to the temptation of shortcuts “because it’s just authorization”.

Alrighty, more and more abstract… it must be the low pressure in the cabin 🙂 But please don’t flip the “philosopher” bit on me just yet, all of the above have very concrete aspects that I’ll eventually demonstrate in this feed