August 20, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Object-level Access Control in Applications

  • November 22, 2005
  • By Chad Cook
  • Send Email »
  • More Articles »

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.





Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel