Object-level Access Control in Applications
Access control is the method and mechanism by which an entitya user, system, application, moduleis granted or denied access to something. This "something" could be just about anythinganother 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 identityan 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 entitythe userwill 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:
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 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 objecta 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 technicalfor 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
The following sequence of events shows the process for access control decisions. This sequence assumes that the entity already has been authenticated:
- Entity requests an object or data.
- Access Control service verifies request against security policy.
- If access is granted, the request is handled:
- Requests can be passed on to target entities for fulfillment.
- Requests can be filled by the access control service.
- 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 objectshow much knowledge the access control service needs to have about all of the data types being handled.