11.3 User Authorization Requirement Patterns

11.3 User Authorization Requirement Patterns

The purpose of access control is to restrict users to doing and seeing only what they should. This section talks about "what a user can do and see" as a concise way of referring respectively to the functions and the information they can access. Collectively they are referred to as privileges that they confer upon a user (or "access rights" or "permissions," though this book calls them privileges throughout). It's also worth recognizing that as far as a system is concerned, a user never does anything directly, so we mean what various parts of the system do on a user's behalf.

Access control is used most widely to control which functions someone can use. For example, a customer service operator could be granted access to all customer service functions, but little else. Functional access control can be extended to individual actions within a function (such as the ability to change, but not to add)-and while greater granularity gives more control, it takes more work both to develop and to maintain. Access control requirements can also restrict the information a user can see and can be used for other purposes (the commonest of which are spelled out in the specific authorization requirement pattern). These ways can be applied in combination. For example, a user might be granted access to one set of functions for one company and a different set of functions for another company. But this can get complicated: if you get away with authorizing access to functions and to information independently, life is much simpler.

There are two types of user authorization requirements: the first defines specific privileges (according to some access rule, such as for a named set of users); the second demands a general ability to configure who can do what. Each has its own requirement pattern. You can use both in a specification, in which case a configurable authorization requirement guides the capabilities of the system, and to guide its configuration, you can use specific authorization requirements (acting as a useful place to put knowledge gathered, to make setting up the system easier). A configurable authorization requirement is in effect an instruction to implement an access control infrastructure.

Regardless of how you choose to define who can do what, you should start by stating what access is allowed in absence of any guidance to the contrary. After all, a requirement saying that "A can do X" has little force if there's nothing to prevent everyone else from doing X. The most sensible approach to take is denial by default. That is, everything is to be inaccessible to every user, unless permission is granted to them either explicitly or by defining some things as publicly accessible.

The denial by default rule can either be specified as a special kind of specific authorization requirement, or it can be incorporated within the main configurable authorization requirements (as the first two example requirements in the configurable authorization requirement pattern do).

Bring as much of the system's activities within the ambit of access control as possible. Many system administrators, database administrators, and developers believe they're exempt from controls that apply to mere mortals. This mentality permeates many products, unfortunately, which can make it difficult to control them. Another difficulty with products is that they're unlikely to be amenable to cooperating with any access control regime you put in place. This could influence product selection decisions if you're serious about security.

Extra Requirements

Regardless of how you choose to specify user authorization, there are a few extra topics worth considering:

1. Presentation and usability To bring navigation of the system into line with what the user can actually do and see, rather than wasting their time by showing functions they're not allowed to use.

2. Delegating authority To let one person act on another's behalf.

3. Preventing loopholes To prevent our efforts at access control being circumvented.

Each of these topics has it own subsection that follows. One more does not, because it's covered in its own requirement pattern:

4. Approval Some activities might warrant approval by a second person (or even a third) before they can proceed. This topic is discussed in the approval requirement pattern.

Presentation and Usability

Systems have a natural inclination to appear stupid unless special steps are taken to prevent it. Denying access is one thing; not looking stupid in the process is something else-and one worth treating carefully, because it can save much time, effort, and frustration during the life a system. Don't clog menus with functions that the user isn't authorized to use; don't let them choose values that they're not allowed to, only to slap them in the face if they try.

How much should we tell users about the existence of things to which they're not allowed access? It's naïve to assume they'll not be aware of most of them in one way or another. (It's impractical to produce lots of different sets of user documentation, for instance-though online documentation attached to each function suffers less from this difficulty.) It's counterproductive to hide the existence of some functions, because a user might need to ask someone with extra privileges to do something for them-so they must be aware that other person can do more than they can. Awareness of inaccessible data is a different matter; in a multi-company system, for example, it might be essential to hide other companies completely.

Here are a few example requirements that aim to make access control more friendly in various ways:

Open table as spreadsheet

Summary	Definition
Hide inaccessible functions	Places from which functions are normally selected (for example, in menus and as buttons or hyperlinks) shall not display functions to which the current user does not have access.
Disable controls for inaccessible functions	Places from which functions are normally selected (for example, in menus and as buttons or hyperlinks) shall display in a disabled manner those functions to which the current user does not have access.
Selection criteria omit inaccessible values	Selection criteria displayed by functions (such as inquiries and reports) shall not display values associated with data the user is not authorized to see (for example, in drop-down lists from which values can be chosen).
Let start only if can finish	The system shall not allow a user to begin an activity if they are not authorized to complete it. The motivation for this requirement is to avoid frustrating users.

Delegating Authority

Real businesses are intricate beasts whose managers quite reasonably want to decide who performs what tasks. If managers need a system to offer a particular kind of operational flexibility, it must be expressly built into the system. One kind of operational flexibility involving access control is the ability to delegate authority to someone else, as in this example:

Open table as spreadsheet

Summary	Definition
Delegate authority	An employee shall be able to grant authority to another employee to act on their behalf. The delegator shall be able to nominate which privileges the delegatee can exercise in their name, including setting access-related limits. The motivation for this requirement is to allow a personal assistant to perform administrative tasks in place of the manager for which they work.
Assume delegated authority	An employee who has the authority to act on another employee's behalf shall be able to indicate to the system that they wish to do so. Any action they take thereafter shall carry the imprimatur of both users (done by B on behalf of A). When they have finished, they shall be able to indicate they have stopped acting on the other employee's behalf. Note that assuming delegated authority can grant a user privileges they do not normally have.

Preventing Loopholes

It's possible to implement access control as a thin veneer around a system that, once punctured, leaves the system completely unprotected. It's not the responsibility of requirements to figure out every kind of attack and the provisions needed to guard against it, but we can write requirements that point out potential loopholes we want to guard against, like this one:

Open table as spreadsheet

Summary

Definition

Cannot bypass authentication

It shall not be possible to cause any part of the system to take any action on behalf of a user unless that part of the system has evidence that user has been authenticated. The intent of this requirement is to guard against being able to bypass normal controls to ask a system component to do something directly. This applies in particular to server processes (for example, where one process checks the user's identity and another process does whatever it's told).