Chapter 11: Access Control Requirement Patterns

Overview

Access control lets us nominate all the people we're prepared to let in, check each one's identity when they visit, limit their access to only what they should see and do, and see who did what-so we needn't trust anyone more than we have to. These are essential features of almost every serious commercial system, and few do it well.

Access control comprises three main activities, which are the subjects of the following requirement patterns (as shown in Figure 11-1):

1. Making people known to the system (user registration).

2. Recognizing a user as a known person (user authentication).

3. Controlling what a user is allowed to do and see (user authorization). This is divided into two requirement patterns, because there are two different types of requirement: the first is for stating a concrete access control rule (specific authorization); the second says that the definitions of who can do what can be changed dynamically (configurable authorization), so you can avoid the nitty-gritty in the requirements.

Figure 11-1: Requirement patterns in the access control domain

In summary, registration decides which people we'll let in; authentication lets them in; authorization decides what they can do when they're in. The third is the goal, and the first two merely prerequisites.

There's one further requirement pattern in this domain: approval, for situations where one user needs to approve the action of another before the action is allowed to proceed. This takes us a little beyond strict access control, but it's so closely related that it fits comfortably within this domain.

Another important aspect of access control is recording who did what ("audit trails"). This topic is covered in the chronicle requirement pattern in Chapter 7, "Data Entity Requirement Patterns," which includes several example requirements that relate to access control-related activities. Write requirements to demand that the use of all functions related to access control be recorded: it's hard to envisage reasons why you wouldn't.

User Accountability

Once a user has been authenticated (has logged in), it's possible to tie them to-that is, make them accountable for-all the actions they perform, which is very useful in its own right. It's the basis of non-repudiation, which is the ability to prove a user did something they deny doing (particularly of a financial nature). Associating an action with the user who initiated it is usually covered by other requirements (such as for functions and chronicle entries).

If you're serious about user accountability, decide which user (if any) is responsible for background processing-so that there's always a person who is ultimately responsible for each thing a system does and who has a strong incentive to see that it is performed properly. For example, if a background process calculates monthly fees for all customers, was it, in some sense, performed by whoever initiated it? Or if it's kicked off automatically at a certain time each month, is the person who originally set up the schedule responsible ever after? Define what you decide in suitable requirements. If you don't, the system might do things for which no one has responsibility. That happens by default in almost all systems, but it's probably not a good thing. After all, shouldn't the buck stop somewhere?

Access control is the only aspect of security for which this book has requirement patterns, though there are many other aspects. The reason is that it's the only aspect that needs to be specified in detail in requirements, because access control forms an integral part of a software system itself. The recording of important "audit trails" in chronicles does, too, for the same reason. But most other forms of security can be implemented externally, like a cocoon around our precious software: a secure physical environment, firewalls, vetting of trusted employees, security procedures, and so on. You need to specify whichever of these things are within your scope-but little more than a straightforward statement of its necessity often suffices (for example, "The system shall be protected from external attack by a respected firewall product"). You can go into more detail if you like, but you must determine for yourself what else to say; that's beyond the scope of this book.

Access Control Infrastructure Considerations

Access control is important, applicable to all serious systems, and tricky to implement, so it deserves an infrastructure of its own. But this is easier said than done. First of all, what's its scope? If we stick to the basics, we don't get the full benefit. If we make it richer, it quickly becomes very intricate-with all sorts of interfaces needed between various parts, in part because we'll want to control access to the tools used to configure access control.

The following diagram shows the main areas of functionality (plus responsibility for approving actions) and some of the logical interactions between them:

Other complications are that an access control infrastructure has maintenance functions that need to be integrated with the main system's user interface. It's also essential that the access control functions be secure; we don't want rogue software to trick the infrastructure into logging someone in, for instance, so the actual interactions could involve intricate protocols.

So while an access control infrastructure is an attractive idea, it's not possible to describe one here that would suit a wide variety of environments. This also explains why it's so hard to get third-party products to integrate with an access control regime, and why so many systems are disjointed as a result.

Access control-related requirements are necessarily often written by people who don't know a lot about security, because few organizations have a security expert on hand or can justify the expense of engaging one just to help write a few requirements. Fortunately, the requirements don't need to grapple with the intricacies of the subject or worry about the implementation challenges, which are considerable. As a result, neither do the requirement patterns here: they don't attempt to say what to do to make a system secure. So if you're going to bring in an expert, it can be more effective to do so after specifying the requirements. Anything to do with security is harder to achieve than it appears-because it doesn't merely have to function; it must also remain steadfast under attack, leaving no holes. Any bricklayer can build a wall, but one that resists determined assault is another matter.