Access Matrix

The access matrix model is the policy for user authentication, and has several implementations such as access control lists (ACLs) and capabilities. It is used to describe which users have access to what objects.

The access matrix model consists of four major parts:

• A list of objects
• A list of subjects
• A function T which returns an object's type
• The matrix itself, with the objects making the columns and the subjects making the rows

In the cells where a subject and object meet lie the rights the subject has on that object. Some example access rights are read, write, execute, list and delete.

Example Access Matrix:

	Objects
Subjects	index.html file	Java VM Virtual Machine
John Doe	rwld	x
Sally Doe	rl	-

An access matrix has several standard operations associated with it:

• Entry of a right into a specified cell
• Removal of a right from a specified cell
• Creation of a subject
• Creation of an object
• Removal of an subject
• Removal of an object

Implementation

The two most used implementations are access control lists and capabilities. Access control lists are achieved by placing on each object a list of users and their associated rights to that object. An interactive demonstration of access control lists can be seen here. For example, if we have file1, file2 and file3, and users (subjects) John and Sally, an access control list might look like:

	Objects (Files)
Users	File1	File2	File3
John	RWX	R-X	RW-
Sally	---	RWX	R--

The rights are R (Read), W (Write) and X (Execute). A dash indicates the user does not have that particular right. Thus, John does not have permission to execute File3, and Sally has no rights at all on File1.

Capabilities are accomplished by storing on each subject a list of rights the subject has for every object. This effectively gives each user a keyring. To remove access to a particular object, every user (subject) that has access to it must be "touched". A touch is an examanition of a user's rights to that object and potentially removal of rights. This brings back the problem of sweeping changes in access rights. Here is what an implementation of capabilities might look like, using the above example:

Users
John	file1:RWX	file2:R-X	file3:RW-
Sally	file1:---	file2:RWX	file3:R--

Access restrictions such as access control lists and capabilities sometimes are not enough. In some cases, information needs to be tightened further, sometimes by an authority higher than the owner of the information. For example, the owner of a top secret document in a government office might deem the information available to many users, but his manager might know the information should be restricted further than that. In this case, the flow of information needs to be controlled -- secure information cannot flow to a less secure user. Check out information flow for more information.