Object-level Access Control in Applications

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Access control is the method and mechanism by which an entity—a user, system, application, module—is granted or denied access to something. This “something” could be just about anything—another system, application, file or data. The process by which a decision is made to allow or disallow access can become rather complex. To help deployment of access control, there are several well-understood models that can be used to manage the relationships between requesting entities and the objects to which they desire access. This article presents an overview of access control and applies its use to the internal data of applications.

The most common and well-understood types of access control are those that apply to users and systems. Users authenticate to a system and become members of various groups; then they gain access to specific information that relates to their group or individual identity. Access control also is applied based on the network identity—an individual IP address, host name or network. Often, the underlying Operating System or dependent applications are relied upon to provide some of these access controls. These mechanisms provide a needed level of security, but one should not stop there when looking at access control. Security needs to be considered at all levels and this includes the internals of an application; this article focuses on the use of access control within applications as it applies to the data and objects within it.

Users and systems can be considered as part of the border, or perimeter, of an application. They interface with the application via APIs, networks, and user interfaces. Access to the application and its data is typically a two-part process. Usually, the requesting entity—the user—will identify itself and, based on the result of that authentication step, gain or be denied access to the application in an all-or-nothing manner. The next logical question that an application designer should ask is:

Do the objects and data within the application fall into binary all-or-nothing categories?

In most cases, the answer is no. If they do not fall into these two access categories, all or none, there is a need for a more granular object-level access control framework. These access controls govern the objects that are passed around throughout the application and which provide data to requestors. Objects can be accessed via their member variables or by calls to their methods, all of which may be access-controlled. The idea of analyzing and identifying all of the different granular pieces within an application that would merit from access control can quickly become daunting and the realities of release schedules and business pressures often do not leave the time desired for design. To accommodate these issues, the design of object-level access control mechanisms should be created with these high-level goals in mind:

• Dynamic
• Flexible
• Extensible

A dynamic access control mechanism is one that is designed to allow simple application and modification of privileges. Some applications will have privileges that change frequently; others may be set once and never changed. A flexible mechanism allows granular application of privileges deemed necessary for the application. This includes the ability to specify which members can be seen and modified, as well as which methods may be called. Finally, extensibility is required to allow for an easy to manage application of privileges and access control to new objects as the application grows.

When You Need Access Control

To help identify whether your application needs an object-level access control framework, the following questions can be asked:

• Do different types of entities access and use the application, including users, systems, and other applications?
• Does the application expose any data and objects for use to other entities?
• Is the application part of a group of applications that provides business functions?
• Are there auditing requirements for access to data and methods within the application?

Most applications will benefit from an access control framework. Only the most isolated applications may not need as granular an access control mechanism, but any decision to skip it should be thought about carefully.

To gain a better understanding of access control and its use within applications, it is useful to understand a few common terms:

• Authentication
• Authorization
• Privileges
• Policy

Authentication and access control are often used simultaneously, but it is important to distinguish between them. Authentication is the act of establishing identity. Authorization refers to the right to access. The identity is used to determine authorization to various things; it is usually the precursor to access control decisions. One important aspect of the authentication step is to maintain the identity after initially establishing it. Access decisions can be made unsafe from the following attacks, which can allow mistaken authorization:

• Replay of requests: A rogue client resending previously sent requests
• Spoofing of entities: A rogue client impersonating the client or server
• Insertion of data: Corrupting a flow of requests by inserting a rogue request

To assure safe access control decisions, maintain session information that includes sequencing and integrity checking.

Privileges represent the set of actions or capabilities that an entity can be authorized to perform; this includes calling methods and retrieving data. Privileges come in several forms, depending on the types of operations that are being controlled. Some examples are:

• File system access: Read, write and execute are common; other privileges vary depending on system
• Access to a service: The ability to log in as a particular entity and from where
• Data objects: Read, write, and view (the ability to know the object exists) are common
• Method calls: The ability to call a method and receive return values

The policy determines the privileges that one has available for use and hopefully organizes them into logically. Creating effective policy entails a combination of technical understanding and business understanding. Some guidelines for creating policy are:

• Identify business roles
• Organize privilege needs into related sets
• Apply policy to entities

Access Control Models

There are a number of access control models available. For the purposes of object-level access control within applications, this article focuses on the Role Based Access Control (RBAC), which is one of the most applicable and useful models for internal application control. Some of the most commonly used models are:

• Discretionary Access Control
• Mandatory Access Control
• Role Based Access Control

Discretionary Access Control (DAC) is most well-understood in terms of filesystem access. This means that the owner of an object can control and give access to others.

Mandatory Access Control (MAC) occurs when the owner of an object does not have full control over the object—a higher-order policy governs access control for the object and allows for the creation of security levels that govern access.

Role Based Access Control (RBAC) is a way of controlling access based on the context of the requestor and the relationship to the data in question. The context is the role of the requester, both from a business perspective and the technical—for example, a system manager that is a business role and has technical access to make changes to the running application. Requestors are organized into groups and policies are created that apply to those groups.

Usually, the most applicable access control model for objects within applications is RBAC, due to the types of data and methods being managed, as well as the nature of interactions with users, systems and other applications. There is often a hierarchy and definition of roles that naturally evolves from the expected usage of an application.

When defining access controls for an application, it is important to be context-aware. This means building a framework that meets the needs of the environment in which the application will run. Role Based Access Control is a model by which access policies are organized based on these logical groupings.

The organization for a Role Based Access Control can be broken down into the following major components:

• Access control service
• Policy management

Making Decisions

The following sequence of events shows the process for access control decisions. This sequence assumes that the entity already has been authenticated:

1. Entity requests an object or data.
2. Access Control service verifies request against security policy.
3. If access is granted, the request is handled:
1. Requests can be passed on to target entities for fulfillment.
2. Requests can be filled by the access control service.
4. If access is denied, the errors response is returned.

The choice of how to handle request fulfillment will vary depending on the environment. Consideration should be given for the number of registered clients, request rate, and relationships between objects—how much knowledge the access control service needs to have about all of the data types being handled.

Policy Organization

The policies that are used by the access service for decision making can be organized in a number of different ways. The following are some examples of common policy structures:

1. Enumeration of all applicable objects and the privileges for the given group; this is useful for a concise number of objects but does not scale well.
2. Policies based on precedence, wherein default privileges can be set and excepted as the granularity increases.
3. Strict role-based policies that define a clear hierarchy in the relationship between entities requesting access and the actual data objects.

These policy structures can be thought of in terms of a range from data-driven to role-driven. The data-driven structure is very explicit in applying privileges to various data objects and methods such as:

Policy ConfigurationModifier {
   member ConfigurationObject::N        = read, write;
   method ConfigurationObject::getStats = execute;
}

A precedence-driven policy could be expressed as:

// Defines the methods for managing users
Policy UserManagementMethods {
   Method addUser;
   Method delUser;
   Method listUsers;
}
// Defines the role that will have access to user management methods
Policy SystemManagerRole {
   MemberDefault = read, write;
   MethodDefault = execute;

   // default privileges are applied
   Include UserManagementMethods;
}

Finally, an role-driven structure could be expressed as:

// Define methods to view financial information
Policy ViewMethods {
   Method viewAccounts;
   Method viewCashflow;
   Method viewProfits;
}
// Define methods to change financial information
Policy SetMethods {
   Method setAccountParam;
   Method setCashflow;
   Method setProfits;
}
// Auditor role, should be able to look at the data but not change it
Policy AuditorPolicy {
   ViewMethods = execute;
   SetMethods  = no-execute;
}
// Accountants should be able to look at and change financial
// information
Policy AccountingPolicy {
   ViewMethods = execute;
   SetMethods  = execute;
}

The run-time use of policies can also be handled in different ways:

1. Initialization of policy at start-up time
2. Dynamic/run-time policy queries

The initialization of policies at start-up time can allow for efficient evaluation by storing policy information in data structures that are efficient for lookups, such as hash tables, maps and lists. To make this flexible, it would be necessary to implement a mechanism by which policies can be modified and updated at run-time. Initializing policies at start-up time can be effective if there are a large number of data objects being controlled or if the policies do not change often.

Queries at run-time allow instantaneous updates to policies, but may generate performance concerns if there are a large number of policies and data objects that would need searching. This is most useful for applications where permissions change frequently; for example, privileges that need to change based on time of day, date or environmental factors can best be handled dynamically.

Controlling Access

There are a couple of different architectures for managing access control in the manner described above:

• Hub and spoke
• Distributed

The hub and spoke architecture defines a central point through which all access is managed and by which all decisions for access are made. This architecture typically involves the following process:

• Client registration and identification
• Access request evaluation

For applications where data flow can be controlled, a central point for access decisions can make manageability easier. This model is useful for controlling access from external systems, users, and applications, as well as internally within the application.

To make access decisions, all requesting entities, whether users or other applications, need to be authenticated. Whereas authentication is a topic worthy of its own article, let the following guidelines help define a safe authentication process:

• If using simple tokens for authentication, avoid hard-coding them into the application—these get compiled in and are easily discovered, allowing attackers to forge identities and gain access. Make them configurable and secure any persistent storage (for example, files). Also, change the authentication tokens periodically.
• For user authentication, consider using one of the many standards-based authentication protocols or subsystems over the normal username/password pair. If users connect over the network, be sure to secure the network connection to avoid capture of credentials.
• For application authentication, consider using public key cryptography; if network-enabled, look at TLS and mutual authentication.

Access evaluation is handled by the central service and controls all data flow to, from, and through the application. The service coordinates access decisions, data retrieval, and return of the data and objects to the requesting entity.

In the distributed architecture, there is no central service that handles access control decisions. Instead, the access decisions are handled at the recipient of the request. This can be effective if control of data flow is cumbersome and unable to be centralized through a single point of entry. The complexity arrives in handling the distribution of policies, which can be done explicitly or centralized at the policy level.

Explicit policy distribution occurs by having each target object that exposes access-controlled data load and manage its policies—via a reusable interface, of course. This example may be the only choice for a set of distributed modules within the same application that otherwise do not interact with one another.

An alternative to each module handling policy enforcement is to centralize the policies while letting the access decisions be made locally at each module. A centralized policy server allows ease of management and deployment of policies while letting each module within the application handle the decisions to allow access to data objects.

Whether using a distributed or centralized architecture for managing access control, the following guidelines are useful to assure a solid access control mechanism:

1. Define access control for objects by analyzing the intended usage of the application, its users, their roles, and the relationship to the various types of data within the application.
2. Consider the flow of data inside the application, its modules, and to its borders where other interfaces can interact with it.
3. Create access policies that logically reflect the users of the application and their relationship to objects being requested.

Summary

The use of Role Based Access Control within an application can provide a high degree of security and confidence. This article presents possible architectures and capabilities that can be designed into your applications. A comprehensive application security strategy is one that applies security at multiple levels. Access control should be looked at from those that access the system—users and systems—and at the same time also considering the need for more granular control on individual pieces and types of data. Access control can be integrated into the very foundations of the application, providing security to data and method calls, which is vital for mission critical systems, those with stringent privacy requirements and for auditing purposes. As with all aspects of application security, think about it often and early—design security strength from the beginning.

About the Author

Chad Cook has spent over a dozen years in Information Security that include both product engineering and IT services. Chad has developed IT service security strategies, networks, and policies for organizations including BBN and GTE Internetworking, Infolibria, and the international security consulting firm @stake/Symantec. He has architected and developed security technology for award-winning networking products sold worldwide, including core routers, edge devices, utility hosting systems, and Web services security devices. Chad has nine patents applied for and pending on security analysis, modeling techniques, and security processing acceleration.

Currently, Chad is the VP of Information Security at Lime Group, a New York securities and brokerage organization, where he leads product architecture, infrastructure security, and compliance efforts. Prior to Lime Group, he designed and developed security risk management and threat modeling products as CTO at Black Dragon Software. Chad has held lead engineering and security positions developing products at BBN, GTE, and a number of small companies. Chad is an internationally published author on security topics, having contributed to two books, Maximum Security, 3rd and 4th editions, has been featured in numerous articles and also has written articles for Symantec’s SecurityFocus.com.

A frequent speaker, Chad has spoken at NATO and United Nations forums on security, numerous conferences, analyst’s events, and security summits.