For years we’ve spoken about the 4 “A”s of identity & security - Administration, Authentication, Authorization, and Audit, but maybe it’s time to drop an “A”. Maybe it’s time to speak of “Access Control” which encompasses Authentication (sometimes referred to as “AuthN”) and Authorization (referred to as “authZ”).
In many instances authorization is binary and tied directly to authentication – if a person is authenticated, then they get access to a resource. The authorization is tied only to the authenticated entity. Consider building security, for example – swipe your proximity card and you’re allowed in. Or, in rather more ancient practice, unlock the door with your key and get access. In the former case, the use of the proximity card (the “token”) is probably recorded someplace, so there is at least a rudimentary audit trail. When the key is the “token”, then there is no trail.
Until recently, the same was true concerning access to digital resources – if you authenticated to the system (network, server, application, etc.) then you got access as defined for the username you are using – most typically to a group of resources.
Note that there’s no actual proof that the person being authenticated is the same person for whom that particular account was created. The standard username/password combination that comprises the vast majority of authentication transactions today gives absolutely no assurance that the “proper” user (whatever that means) is the one being granted access. For example, I do password protect my computer (it’s a laptop that travels with me). But my wife knows the password, and has had to use it on rare occasions when I’m not available, but information is needed. The computer has no idea that it’s her and not me who is accessing those resources. Tokens do not improve this situation and biometrics provide only slightly more proof since, in practice, it isn’t the biometric (a picture of your fingerprint, for example) but a key or token created with the parameters of the biometric.
I could, of course, set up a separate account for her so that she could authenticate as herself. But for the purposes she might need to access the PC, she would need at least the exact same authorizations that I have. Creating that second account, though, reduces the security of the system. With two accounts, the risk that a breach could occur is actually doubled – the risk of my account being compromised PLUS the risk that my wife’s account could be.
The usual method of controlling authorizations for a single user is to have multiple authentications for that user, multiple identities if you will. On my Windows system, I need to sometimes authenticate as the Administrative user when I need to access system resources, install/remove software, etc. Most of the time, I authenticate as a User with a more limited set of authorizations. The same is true of ‘nix systems, where the root account is used sparingly, and only when needed. Even within applications, a similar system is observed – most of the time, I would authenticate to a database as a user, but occasionally I need to be the database administrator (DBA) in order to, well, do administrative stuff. Again, in reality, most people don’t do this – although they should – choosing the “ease of use” that authenticating as the more powerful user brings.
The bottom line is that the important thing is the authentication. Get that right (which usually means enter the correct password) and the authorizations flow: it’s all or nothing, black or white, good or bad. But with data breaches, especially the theft of usernames and passwords, seemingly coming more frequently as each day goes by (and you’d think organizations would have learned by now, wouldn’t you?) we need to do something different.
For a dozen years or so what the “thing we need to do” has been identified as is to replace the username/password combination with something “stronger”. But we’ve learned from study after study that there really isn’t anything strong enough – tokens, biometrics, “hardened” passwords are all flawed. While stealing a biometric is tougher than guessing a password, it's a whole lot more difficult to replace a fingerprint than it is to change passwords.
As I’ve said for many years, and as I hope to re-iterate strongly at the upcoming European Identity & Cloud Conference (EIC), context, as part of a well thought out risk-based access management system, is what we need. Some use the phrase “adaptive authentication” to mean, in essence, a dynamic authentication which may require one, two or more factors depending on the circumstances. Still, this is really just one part of risk-based access control. It’s unfortunate that RBAC has come to mean Role-based AC, so we’ll need to come up with a different term – perhaps Risk Managed Access Control (RMAC).
The authentication continues as we’ve always done it – username/password, token, biometric, what-have-you, singly or in combination – but we collect context data (location, platform, date and time, and so on) and evaluate it giving it a risk metric. Alternatively we could use the inverse and call this a “trust metric” – the amount of trust we have in the validity of the identity of the person attempting the authentication. Based on that metric, we grant authorization on a sliding scale, which can be as fine-grained as your rules engine will allow.
We aren’t there yet, but we need to be. The presentations at this month’s EIC can bring us closer. You really should be there.