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 www.saruman.biz/wiki. The web server presents the home page to this entity, which by default has the digital identity of the IP number he is surfing from. The user clicks on "log in" in the top right hand side, and provides the information "user = sixpacjo, password = SuperSecret". The information he puts in the "user" field is attached to this web session, and the user now has the digital identity of sixpacjo. However, the user is still unauthenticated! The Wiki software then checks the username and password against the information in the Wiki database; it turns out that the password provided by the alledged user sixpacjo matches the one stored in the database; since only user sixpacjo is supposed to know this password, the user is now authenticated, i.e. the Wiki software now believes that in this web session it is dealing with the one and only user named sixpacjo. While surfing around, the user notices an omission in a web page, and clicks the "edit" button. After writing in the omitted data, he clicks "Save page". The write request is sent to the wiki software, which then performs an authorization test: it checks if for that particular Wiki page the user sixpacjo has the necessary writing privilege - which he has. Thus, the test "user sixpacjo is allowed to write to this wiki page?" comes back positive: "YES", and the Wiki software stores the edit.

What muddles this example slightly is that all concepts (identity, authentication mechanism, authorization mechanism, privileges) exist in the single entity "wiki software". When we talk about bigger systems, e.g. your whole home server, these concepts can be distributed. e.g. identities can exist in multiple places (passwd file and OpenLDAP database), both authentication and authorization can be performed by (separate) PAM modules, and the privileges consist of read/write/execute permissions on files and directories in the file system on the server. And other systems, like corporate networks, can have identities in one database, and policies (which provide the authorization data) in another.