Agile Data

Implementing Security Access Control (SAC)

Follow @scottwambler on Twitter!

Security access control (SAC) is an important aspect of any system. Security access control is the act of ensuring that an authenticated user accesses only what they are authorized to and no more. The bad news is that security is rarely at the top of people's lists, although mention terms such as data confidentiality, sensitivity, and ownership and they quickly become interested. The good news is that there is a wide range of techniques that you can apply to help secure access to your system. The bad news is that as Mitnick and Simon (2002) point out “…the human factor is the weakest link. Security is too often merely an illusion, an illusion sometimes made even worse when gullibility, naivette, or ignorance come into play.” The go on to say that “security is not a technology problem – it’s a people and management problem.” Having said that, my experience is that the “technology factor” and the “people factor” go hand in hand; you need to address both issues to succeed.

This article overviews the issues associated with security access control within your system. Although it includes a brief discussion of authentication, the primary focus is on authorization, assuring that users have access to the functionality and information that they require and no more. The issues surrounding authorization are explored in detail as well as both database and object-oriented implementation strategies. As with other critical implementation issues, such as referential integrity and concurrency control, it isn’t a black and white world. A “pure object” approach will likely prove to be insufficient as will a “pure database” approach, instead you will need to mix and match techniques.

Table of Contents

  1. Authentication
  2. Authorization
  3. Effective Security Strategies

1. Authentication

Authentication is the act of determining the identity of a user and of the host that they are using. The goal of authentication is to first verify that the user, either a person or system, which is attempting to interact with your system is allowed to do so. The second goal of authentication is to gather information regarding the way that the user is accessing your system. For example, a stock broker should not be able to make financial transactions during off hours from an Internet caf, although they should be able to do so from their secured workstation at their office. Therefore gathering basic host information, such as its location and security aspects of its connection (is it encrypted, is it via a physical line, is the connection private, …), is critical.

There are several strategies that you can follow to identify a client:

2. Authorization

Authorization is the act of determining the level of access that an authorized user has to behavior and data. This section explores the issues surrounding authorization, there is often more to it than meets the eye, and then explores various database and object-oriented implementation strategies and their implications.

2.1 Issues

Fundamentally, to set an effective approach to authorization the first question that you need to address is “what will we control access to?” My experience is that you can secure access to both data and functionality, such as access to quarterly sales figures and the ability to fire another employee respectively. Your stakeholder’s requirements will drive the answer to this question. However, the granularity of access, and your ability to implement it effectively, is a significant constraint. For example, although you may be asked to control access to specific columns of specific rows within a database based on complex business rules you may not be able to implement this in a cost effective manner that also conforms to performance constraints.

The second question that you need to answer is “what rules are applicable?” The answer to this question is also driven by your stakeholder’s requirements, although you may need to explore various security factors that they may not be aware of (they’re not security experts after all). These factors, which are often combined, include:

2.2 Database Implementation Strategies

Let’s start by reviewing the concepts of roles and security contexts. A role is a named collection of privileges (permissions) that can be associated to a user. So, instead of managing the authorization rights of each individual user you instead define roles such as HR_Manager, HR_User, Manufacturing_Engineer, Accountant, and so on and define what each role can access. You then assign users to the roles, so Sally Jones and her co-workers would be associated with the role of Manufacturing_Engineer. Someone else could be assigned the roles of HR_Manager and HR_User if appropriate. The use of roles is a generic concept that is used by a wide range of technologies, not just databases, to simplify the security administration effort.

A security context is the collection of roles that a user is associated with. The security context is often defined as part of the authentication process. Depending on the technology used a security context is maintained by the system, this is very common in GUI applications, or must be passed around by the system, something that is common with browser-based n-tier system. A combination of the two strategies is also common.

Authorization can be enforced within your database by a variety of means (which can be combined). These techniques include:

The primary goal of database security is to ensure that there isn’t any “backdoor” ways to access critical corporate data. Many organizations choose to disallow ad-hoc queries to production databases to help minimize the chance of unauthorized access (as well as to avoid the associated performance problems). Many organizations introduce reporting databases such as data marts to support ad-hoc queries.

2.3 Object-Oriented Implementation Strategies

Because objects encapsulate both data and behavior an object-oriented (OO) authorization strategy needs to include the ability to secure both. This can be problematic because common object-oriented programming languages (OOPLs) such as Java, C#, C++, and Visual Basic do not natively include security features. Instead you must set a strategy, perhaps a combination of the ones listed below, and then follow that strategy. The implication is that you need to verify, through testing and inspections, that your organizational security strategy is being followed.

Yoder and Barcalow (2000) have developed a pattern language for enabling application security. These patterns are:

Although these patterns are straightforward, which is a very good thing, the interesting ones are the two that deal with user interface (UI) issues – Full View With Errors and Limited View. These patterns address the existence issue discussed earlier and commingle it with usability issues.

Authorization can be implemented with your objects following a variety of strategies. These strategies include:

2.4 Implications

In the previous sections you have seen that you have several technical alternatives for implementing authorization rules. You have also seen that each alternative has its strengths and weaknesses. Similar to those concerning referential integrity, there are some important implications for agile software developers:

3. Effective Security Strategies

I’d like to share a few words of advice that have worked well for me over the years: