, Katholieke Universiteit Leuven
, Katholieke Universiteit Leuven
, Katholieke Universiteit Leuven
, Katholieke Universiteit Leuven
, Katholieke Universiteit Leuven
Abstract—Aspect-oriented software development techniques can help modularize the enforcement of application-specific access control policies.
Middleware platforms must cater to a variety of applications. The access control services integrated in these platforms support only access control policies with limited expressiveness and typically enforce only an invocation access policy. 1 Enforcing such a policy only takes into account information in the method invocation and fails to include application state or context in the access decision process. For example, the declarative access control system in Java 2, Enterprise Edition (J2EE) makes decisions based only on application method names and invocation caller roles. This doesn't suffice for distributed applications in which the access control policy relies on application-specific information, such as a workflow's state. For these cases, existing platforms provide an API to interact with the access control service and leave it up to the developer to enforce the application-specific access policy in the code. Embedding this imperative access control makes it difficult to adapt the access logic to new requirements resulting from policy or application changes. Imperative access control enforcement is cross-cutting—that is, it's spread all over the application and entangled in the application functionality.
Our goal was to build a modular access control service that can enforce expressive policies while accounting for application-specific state. This access control service should be bound to an application without requiring invasive changes to the application, so you can change the policy without modifying the application. Moreover, a modular access control service should encompass a reusable authorization engine, which decides on access requests according to a given access policy. Plugging such an engine into the access control service should be straightforward.
To realize these objectives, we treat our access control service as a container-managed service, which an application server provides to the application without the application's awareness. We configure the service using a deployment descriptor. It enforces the desired access policy by intercepting critical operations, calling the authorization engine, and enforcing the engine's decision. For this purpose, the access control service introduces common abstractions: subjects, (target) objects, and actions. We tune the access control service to a particular application domain by making explicit the application-specific information that's needed to evaluate access requests in the application domain. Our approach uses aspect orientation to bind the access control service to an application. Aspect-oriented languages and frameworks obtain a better separation of concerns by providing support to modularize crosscutting concerns. They therefore promise to improve the support of application-level access control services in middleware, or at least the development of enhanced access control modules that are reusable across a variety of applications. 2 We implemented a prototype of our access control service using CaesarJ ( http://caesarj.org), an aspect-oriented language that supports the modularization of the access control logic. 3
We based our design on two concepts, namely an access interface and a view connector. We briefly illustrate these concepts using a small calendar application. You can find a more detailed example elsewhere. 4
We based our calendar application on that of Gerald Brose, Manuel Koch, and Klaus-Peter Löhr. 5 The calendar system lets users book appointments, or entries. Entries can be singular (one entry) or continual (repetitive). A calendar entry involves participants and resources (laptops, projectors, and so on). The following access policy determines access rights for the three main actors (calendar owner, secretary, and employee):
An access interface provides an abstraction layer that reflects only information relevant for access control. An access interface is like a domain model in that it specifies all that's needed to formulate the access policy. In this model, the application is viewed as a set of target objects and subjects. Subjects can make an access request to perform an action on an object.
An access interface consists of several object and subject interfaces (one per role). These interfaces declare the information that the policy might need in the form of attribute declarations. An object interface also declares semantic actions. These semantic actions abstract syntactic actions and represent the security-sensitive operations to which the policy applies.
The UML diagram in figure 1 shows a possible access interface for the calendar application. An entry in the matrix at the bottom of the figure represents each access rule. The condition that must hold for the rule to be applicable is in square brackets. In our approach, the precise syntax and semantics of the language used to express the access rules are not defined in detail. What's important is the amount of information available through the access interface, which contains all information needed to formulate the access policy. In contrast, the declarative role-based access control in existing application containers such as J2EE and COM+ (an extension of the Component Object Model) limits the available information to method name and subject roles.
Figure 1 Calendar access interface and matrix.
In a more general setting, an access interface is an additional abstraction layer over several applications within one application domain. The access interface can contain application-domain-specific information while remaining reusable over different applications. For example, an access interface could introduce concepts such as a high-risk transaction for a financial application domain or emergency access for a healthcare application domain.
The access interface is bound to the application through an application-specific view connector, which you can think of as a kind of deployment descriptor. We subdivide this binding into three parts. To specify the view connector, we need a detailed representation of the application, as in figure 2. Figure 3 contains a snippet of the view connector for the calendar application.
Figure 2 Calendar application UML diagram.
Figure 3 Calendar view connector.
The view connector performs several functions:
Although this simple example illustrates the access interface and view connector concepts, it's too small to show all of the benefits. For example, it implies a one-to-one correspondence between syntactic and semantic actions. For more complex applications, multiple application methods will typically map onto the same semantic action.
In a typical setting, an organization uses one access interface to abstract application details. This single access interface is bound to various applications, using one view connector per application. An organization-wide security officer, who need not be concerned with application details, manages the single access interface. The view connectors, written by application deployers, map application-specific concepts to the more generic concepts identified in the access interface.
As figure 4 shows, we can view the access control service as a collaboration between three entities: a third-party authorization engine, an access interface, and the view connectors, each binding the access interface to a particular application. The view connector uses the access control decision functionality ( checkAccess) each time an application event occurs that is annotated as a semantic action in the access interface. Conversely, the authorization engine can query the view connector through the access interface to retrieve the required object and subject attributes. The authorization engine then evaluates whether an access request conforms to the policy.
Figure 4 Access control service.
We implemented a prototype of our service in CaesarJ. This aspect-oriented extension of Java focuses on a better modularization of cross-cutting concerns into reusable components. Central to CaesarJ is the concept of a Caesar class ( cclass). The Caesar class offers two important features:
The nested classes declared by a Caesar class form a collaboration and are implemented as virtual classes, which are similar to virtual methods. Each subclass of the encompassing (or outer) Caesar class inherits or overrides the virtual classes.
A Caesar class contract has two parts: a provided part, realized by the implementation, and an expected part, implemented by the binding. Composing both binding and implementation through mixin composition results in a deployable aspect (or weavlet). This subdivision into implementation and binding is only conceptual. The current CaesarJ syntax doesn't distinguish between the provided and expected parts of a Caesar class interface.
The support for modularizing cross-cutting concerns lies in the binding. CaesarJ supports the application of the decorator pattern (wrappers) and the declaration of point cuts analogous to AspectJ. 6 A point cut lets you select where in the application's execution to invoke the provided functionality.
We modeled the access interface as an abstract top-level Caesar class, as figure 5a shows. This class declares two nested classes: AccessSubject and AccessObject. AccessObject, in turn, declares a nested class AccessMethod.
Figure 5 (a) An access interface in CaesarJ, an aspect-oriented extension of Java and (b) the access interface for the calendar application.
To implement an access interface for a specific application domain, we extend the AccessInterface and provide the necessary object and subject interfaces. For expected attributes, we provide an (abstract) getter. The access interface for the calendar application might then look like figure 5b.
We leave the choice of a specific authorization engine to the application deployer. The interface for the authorization engine (see figure 6) is independent of the specific access interface bound to the application. It only uses the abstract AccessInterface class. As you can see, the type of parameter m depends on the object instance o (that is, it's a dependent type). This guarantees that m is a valid action on o.
Figure 6 Authorization engine interface.
For the prototype, we implemented the authorization engine ourselves. Integrating existing authorization engines is straightforward: you can write an adaptor to translate the access request into a format the engine understands. The only assumption here is that the engine can cope with the common subject, object, and action abstractions, and with subject and object attributes. We could, for example, integrate the authorization engine with the Ponder 7 or Extensible Access Control Markup Language 8 frameworks with the access service.
In this adaptor implementation, we can choose to push all of the information that the authorization engine might need. Alternatively, we can use a lazy strategy, whereby the authorization engine pulls the attributes using callbacks when needed for evaluating an access request.
We implemented a view connector as a cclass that binds the CalendarAccessInterface to the calendar application as shown in figure 3. ( Figure 7 shows a small part of this implementation.) It does this by extending the corresponding access interface. We distinguish two parts of the implementation:
In the pointcuts, the AccessSubject (line 18) represents the subject that makes the access request. The view connector interacts with a session to retrieve this subject, which represents the active role for a user or process.
Figure 7 Calendar view connector.
CaesarJ doesn't provide explicit support for representing semantic actions. So, we implemented semantic actions as virtual classes in the AccessInterface. Reifying the semantic action lets us keep the authorization engine interface generic. CaesarJ's family polymorphism and dependent types, moreover, render the interface typesafe. Table 1 summarizes how we use CaesarJ concepts to implement the access control service collaboration.
Alternatively, we could implement the semantic actions as (provided) methods on the AccessObject and invoke them in the binding instead of instantiating an AccessMethod object ( figure 7). Implementing the semantic actions this way requires invoking the checkAccess method in every method's implementation. To avoid this code duplication, we could declare a generic pointcut in the AccessInterface, which intercepts each provided method declared by an AccessObject. We also should make provisions such that the application conveys the subject ( AccessSubject) to the authorization engine.
In the prototype implementation, we implemented the view connector by hand. However, we should be able to generate the view connector's code given its descriptor.
To what extent did we fulfill our goal?
Current systems can't support access control modularly. Rather, the application developer must enforce the access policy by hard-coding the access logic or embedding calls to an external authorization engine in the application. In the latter case, the developer must ensure that the application conveys all of the information the engine needs for the access request evaluation. Moreover, the application might need to translate the access request into terms the access engine understands before the engine is called. When using the CORBA Resource Access Decision (RAD) service (see the " Related Work" sidebar), for example, the application conveys a protected resource name and access operation to the access decision function, which abstracts the object accessed and the action. Entangling access logic or calls to an authorization engine with business logic makes adapting the enforced access policy difficult.
We modularize the access control implementation through aspect orientation. Aspect orientation lets us define the abstractions required by the access logic as a view onto the application and bind these abstractions to the application modularly.
An open challenge pertaining to services that are transparent to the application is how to deal with exceptions or exceptional conditions originating within that service. In our case, an access denial could potentially occur at each method invocation. Consequently, the application can be left in an inconsistent state. Future work should reveal how and at what cost we can provide recovery/rollback operations.
Common authorization engines include Tivoli Access Manager's authorization server and the RAD service (see the sidebar). Our approach adds to these engines' functionality by making explicit their expectations of the application without compromising their reusability. Thus, deployers can detect inconsistencies early. For example, they can verify whether corresponding view connectors define the mappings of all attributes declared in the access interface.
Our system is an aspect-based subsystem that manages the separation of concerns between security-specific components (such as the authorization engine) and the application logic. Realizing this approach on state-of-the-art middleware technologies requires that the middleware provide support for retrieving application state and additional context information. Consequently, applying the approach to standard J2EE or COM+ environments requires trade-offs. Supporting access interfaces that only need information provided by the middleware platforms is easy. But, when the application needs a more expressive access interface, implementing the view connector might require that you modify the application code before it can retrieve the necessary information.
Application containers that incorporate aspect-oriented concepts, such as JBoss aspect-oriented programming ( http://labs.jboss.com/portal/jbossaop/index.html), are perfect environments for our approach. We've also implemented a prototype on top of Java Aspect Components 9 to demonstrate this, as we describe elsewhere. 4
Although in our prototype the access control service collaboration itself is reusable, we still custom-make the view connector for each application. An interesting question is whether the middleware should support these kinds of aspects by rendering view connector construction more straightforward and even configurable.
Although challenges remain, aspect orientation provides good support for access control modularization. We believe this modularization of platform services is a prerequisite to satisfying the varying and evolving requirements of today's applications.
Our research relates to a number of access control technologies for enforcing application-specific policies. Tivoli Access Manager supports consistent and centralized management across heterogeneous systems by introducing a hierarchical protected object namespace to abstract resources. 1 URL mappings specify these abstractions' binding to the application by determining how the Web resource manager should resolve a dynamic URL into a namespace object. The CORBA Resource Access Decision service abstracts the asset and request by conveying a protected resource name and access operation to the authorization engine. 2 The application must supply these abstractions each time it invokes the authorization engine and can retrieve additional attributes using dynamic attribute services.
Object security attributes are generic representations of application-specific factors. 3 Java authorization contract for containers specifies contracts between the Java 2, Enterprise Edition application container and so-called policy providers. 4 Policy context handlers let providers obtain additional context, such as the enterprise bean involved in the access request. However, these technologies don't capture the authorization engine's requirements for enforcing the access control policy explicitly. View Policy Language aggregates access rights in a type-safe manner into views, which you can assign to a role. 5 VPL aims at a better separation of concerns so that access control is manageable, but focuses on security policy design, specification, and management rather than access control integration.
You can view our approach as an application of the multidimensional separation of concerns 6 tailored to the enforcement of application-specific access control. Bart De Win, Wouter Joosen, and Frank Piessens proved that aspect-oriented software development (AOSD) techniques are useful in the separation of the access control concern. 7 Our approach builds on this work and adds support for an additional abstraction layer that lets several applications within the same application domain enforce a single policy.
The use of AOSD techniques for application-level access control isn't limited to a modularized implementation of access control. Eunjee Song and hercolleagues use an aspect-oriented modeling approach to verify whether composition of the access control concern and the application satisfies specified properties. 8 Hence, their work uses the same technologies as ours but with a different goal. Inlined reference monitors use a program-modification approach to enforce code access security policies on untrusted code. 9 In contrast, our work aims to enforce user-based access control policies.ReferencesG.Karjoth"Access Control with IBM Tivoli Access Manager,"ACM Trans. Information System Security, vol. 6, no. 2,2003,pp. 232-257.K.Beznosovet al.,"A Resource Access Decision Service for CORBA-Based Distributed Systems,"Proc. 15th Ann. Computer Security Applications Conf.(ACSAC 99), IEEE CS Press,1999,pp. 310-319.K.Beznosov"Object Security Attributes: Enabling Application-Specific Access Control in Middleware,"Proc. 4th Int'l Symp. Distributed Objects and Applications(DOA 02), Springer,2002,pp. 693-710.R.Monzillo"Java Authorization Contract for Containers,"v.1.0,2003;http://java.sun.com/j2ee/javaacc.G.Brose"Manageable Access Control for CORBA,"J. Computer Security, vol. 10, no. 4,2002,pp. 301-337.H.OssherandP.Tarr"Using Multidimensional Separation of Concerns to (Re)Shape Evolving Software,"Comm. ACM, vol. 44, no. 10,2001,pp. 43-50.B.De WinW.JoosenandF.Piessens"Developing Secure Applications through Aspect-Oriented Programming,"Aspect-Oriented Software Development,E. Robert et al., eds., Addison-Wesley,2005,pp. 633-650.E.Songet al.,"Verifiable Composition of Access Control and Application Features,"Proc. 10th ACM Symp. Access Control Models and Technologies(SACMAT 05), ACM Press, 2005, pp. 120-129.Ú.Erlingsson"The Inlined Reference Monitor Approach to Security Policy Enforcement,"doctoral thesis, Dept. of Computer Science, Cornell Univ.,2004.
Cite this article: Tine Verhanneman, Frank Piessens, Bart De Win, Eddy Truyen, and Wouter Joosen, "A Modular Access Control Service for Supporting Application-Specific Policies," IEEE Distributed Systems Online, vol. 7, no. 6, 2006, art. no. 0606-o6001.
A PhD grant from the Institute for the Promotion of Innovation through Science and Technology in Flanders (IWT-Vlaanderen) supported this research. This article is an extended version of a paper presented at the First Workshop on Aspect-Oriented Middleware Development. 10 We thank Riccardo Scandariato and the reviewers from both the AOMD workshop and IEEE Distributed Systems Online for their comments and suggestions.