Beyond Authentication, Authorization and Accounting

A very common oversimplification of access control is: "authentication, authorization and accounting". This narrow view obscures many subtle aspects of corporate practices for providing fine grained access to information resources.

Information systems represent users using user accounts or certificates and implement digital equivalents to guarded doors, records and signatures. While user accounts sometimes represent services or information systems instead of people, I will use the term "user" alone for simplicity.

Authentication is seen as a way to check for a users identity, but real implementations do not guarantee this. Every user account has an associated credential that is presented and validated by the system that controls the access to resources before the user of the user account can access those resources (this is called "login"). Upon login, we can't assert the identity of the user, or even if the user account's owner is the current user of the user account. What we do know is that someone who knows the user ID of a valid user account has presented to the system both the user ID and the associated credentials.

When we need to link user accounts and certificates to identifiable users, making users accountable for the use of the user account, we have to complement technical authentication with other controls.

The first control is checking the actual identity of the user before providing him with the set of user ID and credential. In countries were national ID cards exist, this control can be pretty straightforward. In other countries, widely different methods are used, normally checking if the user has information, papers and cards that only the legitimate user should have. I call this control User Registration.

The second control is preventing the user from sharing the credentials with other users. This can be achieved by using multiple credentials (biometric and password, for example)  Other enforcement controls are not as effective; for example one can warn the user of the consequences of sharing  the user ID and credential, and find ways to detect when this happens.

When protecting the anonymity of users is more important than making them accountable, we often need to guarantee that user accounts and certificates are not linked to identifiable users. This does not  mean that anonymous User Registration is trivial, as we often will want the users to fulfill certain criteria, what I call  Personality of the user. Common examples of personality test are: "Are you over 18?", "Do you live in Europe?", or "Are you human?". Anonymous user accounts are not intended to check who the user is, but to check if the user is the same who used the user account the last time it logged in.

It is not rare to find online applications that don't use use accounts at all, checking only for the personality of the user before providing access.

An additional aspect of authentication is session control, which limits:

• The number of login attempts with an invalid credential or user ID; what happens after the limit is reached; the time lapse between login attempts.
• The number of simultaneous sessions with the same user ID;
• The longest duration of a session.

So under the umbrella of "Authentication", we find:

• Validation for the actual identity of identified users OR validation of the Personality of anonymous users (User Registration)
• Provision of user ID's and credentials to users.
• Validation of the matching between user ID and credentials before grating any access to a resource.
• Limits on the usage of the system with a user ID, with or without a matching credential (Session Control)

"Authentication" therefore has three component proofs, which are mixed and matched as needed:

• Proof of identity.
• Proof of personality.
• Proof of ownership of the user account or digital certificate.

The traditional list of types of proof of ownership of the user account is:

• Something you know (passwords)
• Something you have (tokens and private keys)
• Something you are (biometrics)

This list is not complete, we can include:

• Something you like. What if we could test the taste for colors or music of a user, and reliably check it when the user wants to login?
• Something you can do. What if we could test the some ability of a user, like typing patterns, and reliably check it when the user wants to login?
• Something you think.  What if we could test the scale of values of a user, and reliably check it when the user wants to login? (I know, is far-fetched)

Authorization is seen as granting the use of resources to authorized users and deny it to unauthorized users. But, How does a user becomes authorized to use a resource?. A very simple scenario is when there is a Resource Owner, an Administrator, who manages the system, and a User. The user sends an "access rights request" to the resource owner, who can grant the request,  and ask the administrator to technically grant those rights on the resource to the user's user ID. At a later time, the authorized user can use his user ID and credential to authenticate to the system, and use the resource using the rights he has been granted.

So under the umbrella of "Authorization" we find:

• Access Rigths Control
• Authorization

Under the traditional Accounting concept of access control there are two distinct processes, Recording and Signing.

Recording registers accurately the results of access to resources, so these can be investigated and will and intent or responsibilities determined. The recording process will normally have to meet objectives for accuracy, including date and time. Recording normally registers;

• Interface ID and Location;
• User account or certificate ID;
• Signature;
• Type of Access Attempt (login, logout, change password, change configuration, connect/disconnect systems, repositories I/O interfaces, enabling/disabling admin access or logging, etc)
• Date and Time of Access attempt;
• Access attempt result;
• Resource accessed.

Signing records the will and intent about a "document" (or a mail, video, song, photo, etc) of the owner of the user account or certificate concerning a document, such as agreeing, witnessing or claiming authorship of documents like original works, votes, contracts and agreements. Digital signatures are a special kind of record.

A digital signature using public key encryption allows for authentication of documents, but what does a digital signature actually authenticate?. You can assert third parties authorship sometimes. For example "I know that this was written by Abel because it is signed with his private key, no one contests his authorship, and Abel doesn't claim that his private key has been stolen".

But what you can't do is to assert your own authorship. Why? Because you can get a message from Abel, remove the digital signature and add your own, asserting that you are the author.

This is the reason why signing contracts can potentially become complicated. I could send you a signed contract, which you sign and send back for me to sign, which I could again sign to show I agree with your signing it, and send it to you so you can prove that I am committed to the contract, as the first signature only shows agreement to my own writing.

Summarizing, "Authentication, Authorization and Accounting" is an oversimplification for:

• User Registration.
• Provision of user ID's and credentials to users.
• Authentication.
• Session Control
• Access Rights Control
• Authorization
• Recording
• Signing

I hope UPASAARS doesn't become a popular acronym...it looks ugly, doesn't it?

A final word on the equivalence between user accounts and digital certificates. A digital certificate serves the same purpose a user account does; providing and denying access to resources to people depending on what we know about them and how much we trust them.

For user accounts:

• User Registration, provision of user ID's and credentials to users is performed in house.
• The user account has a user ID and a credential or set of credentials.
• Session Control is configured normally system by system.
• Access Rights are granted or denied depending on the users identity and personality.

For digital certificates:

• User Registration, provision of user ID's and credentials to users is performed by a certification authority.
• The digital certificate has a Distinguished Name (equivalent to the user ID), and a credential (public key signed by a certification authority+private key) , which is a credential of the type "something you have".
• Session Control is still configured system by system.
• Access Rights are granted or denied depending on how much we trust the guarantees the certification authority provides about the users identity and personality.

The advantage of digital certificates over user accounts is that they scale; we can trust users that haven't gone through our own User Registration,  the disadvantage is that we can trust them only as much as we trust their Certification Authority regarding their User Registration quality in terms of how do they check their users identity and personality.

This is what OpenID ultimately tries to accomplish, without relying solely on digital certificates.

Bonus: Check these Identity Management videos from The Open Group!