Authentication, authorization and privileges

When dealing with security, there are a couple of terms that keep coming back, and that are slightly narrower in scope than people usually believe. These terms are authentication, authorization and privilege, and they all deal with identity.

Identity

When we're talking about IT security, we're essentially talking about things related to digital identity. Without recreating a whole scientific piece about it, we can put forward the following relevant observations:

a digital subject is an entity with a digital identity attached to it, e.g. the human Joe Sixpack with the digital identity "sixpacjo", or the machine humming in my attic with the digital identity www.saruman.biz attached to it;
a digital subject can be human or non-human. Examples are: a user (obviously), a server, a web site, a message et cetera;
a digital identity has one or more identity attributes. Examples are: a name, a login name, a surname, group membership(s), access flags, a URI, an email address, a picture file (digital photo) et cetera;
the holder of a digital identity does not want to present all the identity attributes to everyone. E.g. you don't show your passport, drivers license and social security number to the waiter at the restaurant where you reserved a table, and you don't give your e-mail address to every website you visit (at least, we hope you don't!). Thus, for each process that needs a digital identity, the holder wishes to present only those attributes that are necessary and agreed upon by both sides.

Authentication

The question of authentication can be reduced to a single central question: is the entity indeed who he/she/it claims to be? Slightly more formal: when an entity claims to be a certain digital subject, can we trust this to be true? For an example: the user logging in to the server claims to be "root" - but is this really our own administrator, or is this a malicious cracker? Usually, a digital identity authenticates itself by presenting a unique object, a unique piece of information. In real life, authentication can be by use of your passport or credit card; in computers, we very often see the use of passwords or passphrases. But of course, a user could authenticate by presenting a fingerprint scan, or a one-time pass token that the system knows has been issued to the user that this digital identity claims to be.

Privilege

Ahh, this is what it's all about: what privileges can we get? A privilege can be reduced to the simple question what is it that the digital subject wants? This basically means read access to information, write access on information, permission to execute a program or script, or permission to perform any other action within the system. The simple fact that a user has sufficiently proven that he is who he claims to be (e.g. digital entity "sixpacjo") does NOT mean that he gets to perform the action that he requested; editing the time zone file /etc/timezone on my home server is strictly reserved to digital entity "root", even though "sixpacjo" does enjoy the privilege of reading this file, if he so pleases.

Authorization

So with the above, it's now pretty clear what we mean by authorization: Is the user allowed to do this? Or a bit more formal: does the entity have permission to exercise a privilege? Thus, an authorization question should always be answerable with "yes", "no" or "not enough information". In the example above: user "sixpacjo" does not have the privilege of editing my timezone file; when he tries, the authorization mechanism in my server must provide answer "no" on his attempt. This means that when "sixpacjo" tries to write to my timezone file, he gets "permission denied" from the program that does the write attempt (e.g. the shell or vi).

Wrapup

Let's go through a scenario that uses all the above terms: a user surfs onto the Wiki [1]. He