Authentication and Authorisation in Information Systems
6 April 2024
All clients send requests to execute some operation on a server. Some clients send requests to execute unintended operations on the server. To protect against the latter, the server has to verify two conditions before a request can be executed:
The verification of the first condition is called authentication, the second is called authorisation. Both presuppose that the client has established some kind of first contact with the server to establish trust. During first contact, the client sends a secret to the server; the server stores the client secret and generates an authorisation set for the client:
┌──────┐ ┌──────┐ ┌─────────┐
│client│ │server│ │ store │
└───┬──┘ └───┬──┘ └────┬────┘
│ │ │
├───secret─────────────────────▶│
│ │ │
│ ├────auth set────▶│
│ │ │
The client secret is used to verify the client's identity in all subsequent requests sent. The authorisation set is used to specify the set of operations that the client is allowed to execute.
After first contact, whenever a client sends a request claiming to be a trusted entity, the client send its secret, and the server performs a lookup to check whether this secret matches the initial secret sent by the client during first contact. If this is the case, then the first condition is verified.
Verifying the second condition is trivial. The server performs a lookup to retrieve the authenticated client's authorisation set, and checks whether the requested operation is part of the client's authorisation set.
*
Implementing Authentication. Authentication may be implemented in its simplest form as a table. Whenever a client establishes first contact, a new entry is inserted into this table. When a request containing a secret is received, the server performs a lookup into this table to verify that the secret matches at least one secret received during all prior first contacts.
┌─────────┬─────────────┐
│client id│client secret│
├─────────┼─────────────┤
│ 0 │ hello │
├─────────┼─────────────┤
│ 1 │ world │
└─────────┴─────────────┘
One simple augmentation that can improve the effectiveness of the system immediately is to apply a hashing strategy. Instead of storing the client secret directly, the server stores a hash of the client secret. This way the client secrets are not immediately exposed in case of a table leak.
┌─────────┬─────────────┐
│client id│client secret│
├─────────┼─────────────┤
│ 0 │ 2cf24dba5fb0│ ◀── hash
├─────────┼─────────────┤
│ 1 │ 83b2ac5b9ed2│ ◀── hash
└─────────┴─────────────┘
Another way to improve the system is to use introduce sessions. Sessions are created after a client has authenticated itself, and they last for a set period of time. During this period, the server can skip authentication for consecutive requests from the same client. To implement sessions, a new table is created, which stores a set of session keys. Each session key represents a client that has been recently authenticated.
┌──────────┬──────────────┬─────────┬──────────┐
│session id│ session key │client id│expires at│
├──────────┼──────────────┼─────────┼──────────┤
│ 0 │ a6ddc7d39eb0│ 0│ 10342890│ ◀──── expired session
├──────────┼──────────────┼─────────┼──────────┤
│ 1 │ 1c5b97264c69│ 0│ 10648002│ ◀──── live session
├──────────┼──────────────┼─────────┼──────────┤
│ 2 │ 1c5b97264c69│ 1│ 10651239│ ◀──── live session
└──────────┴──────────────┴─────────┴──────────┘
If a client has not been authenticated recently, they will have to initiate the authentication protocol and send their secret to the server. After verifying the client's identity, the server generates a session key for the client and insert both as a pair into the sessions table. The server then sends the session key to the client. The client sends all subsequent requests using this session key instead of its secret. Also, the server refreshes the session key during all subsequent requests, provided that the session has not expired.
┌──────┐ ┌──────┐ ┌─────────┐
│client│ │server│ │ store │
└───┬──┘ └──────┘ └─────┬───┘
│ │ │
│ │ │
├───secret─────▶├───────lookup────────▶│
│ │ │
│ ◀───────lookup ok──────│
│ │ │
│ ├───────session key───▶│
│ │ │
◀──session key─────────────────────────│
│ │ │
│ │ │
│ │ │
│ op request │ │
├──(+ session ─▶├───────lookup────────▶│
│ key) │ │
│ ◀───────lookup ok──────│
│ │ │
│ ├─refresh session key─▶│
│ │ │
│◀──op response─┤ │
│ │ │
Implementing Authorisation. The simplest way to implement authorisation is to use a table. The server can verify whether a client is authorised to execute a request by performing a lookup into this table.
┌─────────┬───────────────┐
│client id│client auth set│
├─────────┼───────────────┤
│ 0 │ (admin) │ ◀──── 1-d tuple
├─────────┼───────────────┤
│ 1 │ (standard) │ ◀──── 1-d tuple
└─────────┴───────────────┘
┌─────────┬───────────────┐
│client id│client auth set│
├─────────┼───────────────┤
│ 0 │ (create, x) │ ◀──── 2-d tuple
├─────────┼───────────────┤
│ 0 │ (read, x) │ ◀──── 2-d tuple
├─────────┼───────────────┤
│ 0 │ (update, x) │ ◀──── 2-d tuple
├─────────┼───────────────┤
│ 0 │ (delete, x) │ ◀──── 2-d tuple
├─────────┼───────────────┤
│ 1 │ (read, x) │ ◀──── 2-d tuple
└─────────┴───────────────┘
The range of the client auth set depends on the granularity of the operations exposed by the server. For example, in a highly granular system where authorisation is granted at the level of individual operations on individual resources, the range of the client auth set may be a 2-d tuple of the form (operation, resource). In a less granular system, the range of the client auth set may be a 1-d tuple of the form (role).
One way to manage complexity in a highly granular system that uses 2-d tuples is to use an auxiliary table with a smaller range of 1-d tuples. Each 1-d tuple in this auxiliary table maps to a set of 2-d tuples in the main table. Each client is then assigned a 1-d tuple from the auxiliary table.
┌─────────┬────────────────┐
│client id│ role │
├─────────┼────────────────┤
│ 0 │ (admin) │
├─────────┼────────────────┤
│ 1 │ (standard) │
└─────────┴────────────────┘
┌────────────┬─────────────┐
│ role │ op-resource │
├────────────┼─────────────┤
│ (admin) │ (create, x) │
├────────────┼─────────────┤
│ (admin) │ (read, x) │
├────────────┼─────────────┤
│ (admin) │ (update, x) │
├────────────┼─────────────┤
│ (admin) │ (delete, x) │
├────────────┼─────────────┤
│ (standard) │ (read, x) │
└────────────┴─────────────┘