IEEE DISTRIBUTED SYSTEMS ONLINE 1541-4922 © 2006 Published by the IEEE Computer Society June 2006 (vol. 7, no. 6), art. no. 0606-o6001
A Modular Access Control Service for Supporting Application-Specific Policies Tine Verhanneman, Frank Piessens, Bart De Win, Eddy Truyen, and Wouter Joosen • Katholieke Universiteit Leuven
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 crosscutting—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
IEEE Distributed Systems Online June 2006
1
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, an aspect-oriented language that supports the modularization of the access control logic.3
Access control service design 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): z
A calendar owner is an employee who can create, edit, and delete both singular and repetitive entries. However, the owner can’t book resources for these entries.
z
A calendar owner’s secretary is an employee who can create only singular entries and edit existing entries in the owner’s calendar. The secretary can also book the necessary resources.
z
All employees can access the information in a calendar, but only the owner or the owner’s secretary can change it.
Access interface 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
IEEE Distributed Systems Online June 2006
2
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 applicationdomain-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. View connector
IEEE Distributed Systems Online June 2006
3
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: z
It decides how application objects map to (target) objects and subjects. For example, it
IEEE Distributed Systems Online June 2006
4
can define object instances of type Calendar and Entry as instances of CalendarObject. z
z
It determines how to compute the necessary attributes for target objects and subjects. For example, the view connector in figure 3 maps the calendarOwner attribute to the method getOwner() on Calendar. It identifies all security-relevant operations on application objects that map to target objects and associates them with the corresponding semantic actions in the object interface. For example, all methods on Calendar representing an editEntry action—that is, updateEntry(..) and addUserToEntry(..)—are labeled as such.
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. Access control service 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.
IEEE Distributed Systems Online June 2006
http://dsonline.computer.org/portal/site/dsonline/menuitem.3a529f3832e8f1e13587e060... 6/14/2006
5
Figure 4. Access control service.
Implementation 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: z
it declares a set of collaborating nested classes, and
z
it specifies not only what it provides, but also what it expects from the application to fulfill its contract.
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
IEEE Distributed Systems Online June 2006
6
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. Access interface 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. public abstract cclass AccessInterface{ public abstract cclass AccessSubject{} public abstract cclass AccessObject{ public abstract cclass AccessMethod{} } } (a)
public cclass CalendarAccessInterface extends AccessInterface{ //[SubjectInterfaces] public cclass EmployeeSubject extends AccessSubject{} public cclass SecretarySubject extends EmployeeSubject{} public abstract cclass CalendarOwnerSubject extends EmployeeSubject{ public abstract SecretarySubject getSecretary(); } 10 //[ObjectInterfaces] public abstract cclass CalendarObject extends AccessObject{ public abstract CalendarOwnerSubject getCalendarOwner(); public cclass NewEntry extends AccessMethod{} … }
20
public cclass ResourceObject extends AccessObject{ public cclass Book extends AccessMethod{} … }
} (b)
IEEE Distributed Systems Online June 2006
7
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. Authorization engine 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. public abstract cclass AuthorizationEngine{ public abstract boolean checkAccess(AccessInterface.AccessSubject s, final AccessInterface.AccessObject o, o.AccessMethod m); } 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 Ponder7 or Extensible Access Control Markup Language8 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. View connector 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: z
Wrappers (lines 2–14 in figure 7) implement the retrieval of attributes for both target
IEEE Distributed Systems Online June 2006
8
objects and subjects. These attributes can be retrieved from the application object itself (using the wrappee construct) or declared by the wrapper. z
Pointcuts (lines 15–22) translate application-specific requests in terms of the access interface wherever applicable and invoke the authorization engine. Depending on the access decision, the call proceeds or the enginereports an access failure.
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. public cclass CalendarViewConnector extends CalendarAccessInterface{ //[Wrappers] public cclass CalendarWrapper extends CalendarObject wraps Calendar{ public CalendarOwnerSubject getCalendarOwner(){ return CalendarOwnerSubject(wrappee.getOwner()); } } public cclass CalendarOwnerSubject wraps User{ 10 public SecretarySubject getSecretary(){ return SecretarySubject(wrappee.getSecretary()); } } … //[Pointcuts] void around(Calendar c) : (execution(void Calendar+.updateEntry(. .)) && this (c)){ final CalendarObject cao = CalendarWrapper(c); if (authorizationEngine.checkAccess(getAccessSubject(),cao,cao.new EditEntry())) proceed(c); 20 else {reportAccessDenial(new AccessDenial("Calendar.updateEntry");} } … } Figure 7. Calendar view connector.
Motivation 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.
IEEE Distributed Systems Online June 2006
9
Table 1. Mapping of CaesarJ concepts to the access control service implementation. Access control service
CaesarJ
Authorization engine
Collaboration interface (provided operation)
Access interface:
Collaboration interface:
objects and subjects
abstract nested classes
actions
concrete nested classes
attributes
expected operations (declaration)
View connector:
binding
domain mapping
wrappers
information retrieval
expected operations (implementation)
semantic actions +
pointcuts
checkAccess
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.
Evaluation To what extent did we fulfill our goal? Modular binding to the application 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.
IEEE Distributed Systems Online June 2006
10
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. A reusable authorization engine for enforcing expressive policies 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. Middleware support for access control 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 tradeoffs. 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, are perfect environments for our approach. We’ve also implemented a prototype on top of Java Aspect Components9 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.
IEEE Distributed Systems Online June 2006
11
Acknowledgments 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. References 1.
Object Management Group, “Security Service Specification,” v.1.8, 2002.
2.
P.T. Devanbu and S. Stubblebine, “Software Engineering for Security: A Roadmap,” Proc. Conf. Future of Software Eng. (ICSE 00), ACM Press, 2000, pp. 227–239.
3.
M. Mezini and K. Ostermann, “Conquering Aspects with Caesar,” Proc. 2nd Int’l Conf. Aspect-Oriented Software Development (AOSD 03), ACM Press, 2003, pp. 90–99.
4.
T. Verhanneman et al., “Uniform Application-Level Access Control Enforcement of Organization-wide Policies,” Proc. 21st Ann. Computer Security Applications Conf., IEEE CS Press, 2005, pp. 431–440.
5.
G. Brose, M. Koch, and K.-P. Löhr, “Integrating Security Policy Design into the Software Development Process,” tech. report B-01-06, Institut für Informatik, Freie Universität Berlin, 2001.
6.
G. Kiczales et al., “Getting Started with AspectJ,” Comm. ACM, vol. 44, no. 10, 2001, pp. 59–65.
7.
N. Damianou et al., “The Ponder Policy Specification Language,” Proc. Policy 2001, LNCS 1995, Springer, 2001, pp. 18–28.
8.
Organization for the Advancement of Structured Information Standards, “Core Specification: Extensible Access Control Markup Language,” (XACML) v.2.0; www.oasisopen.org/committees/xacml.
9.
R. Pawlak et al, “JAC: A Flexible Framework for AOP in Java,” Proc. Reflection 2001, LNCS 2192, Springer, 2001, pp. 1–24.
10.
T. Verhanneman et al., “Implementing a Modular Access Control Service to Support Application-Specific Policies in CaesarJ,” Proc. 1st Workshop Aspect Oriented Middleware Development (AOMD 05), ACM Press, 2005, pp. 1–6. Tine Verhanneman is a PhD research student in the Department of Computer Science at the Katholieke Universiteit Leuven. Her research interests include application-level access control and aspect-oriented software development. Verhanneman received her master’s degree in computer science from K.U. Leuven. Contact her at DistriNet, Dept. of Computer Science, K.U. Leuven,
IEEE Distributed Systems Online June 2006
12
Celestijnenlaan 200A, B-3001 Leuven, Belgium;
[email protected]. Frank Piessens is a professor in the Department of Computer Science at the Katholieke Universiteit Leuven. His research interests include software security aspects, including security in operating systems and middleware, security architectures, application security, secure programming languages, Java and .NET security, and software interfaces to security technologies. Piessens received his PhD in computer science from K.U. Leuven. Contact him at DistriNet, Dept. of Computer Science, K.U. Leuven, Celestijnenlaan 200A, B-3001 Leuven, Belgium;
[email protected]. Bart De Win is a postdoctoral researcher in the Department of Computer Science at the Katholieke Universiteit Leuven. His research interests include security engineering, access control, aspectoriented software development. De Win received his PhD in computer science from K.U. Leuven. Contact him at DistriNet, Dept. of Computer Science, K.U. Leuven, Celestijnenlaan 200A, B-3001 Leuven, Belgium;
[email protected]. Eddy Truyen is a postdoctoral researcher in the Department of Computer Science at the Katholieke Universiteit Leuven. His research interests include middleware, dynamic customization of distributed systems and services, collaboration-based design, component-based design, and aspect-oriented software development. Truyen received his PhD in computer science from K.U. Leuven. Contact him at DistriNet, Dept. of Computer Science, K.U. Leuven, Celestijnenlaan 200A, B-3001 Leuven, Belgium;
[email protected]. Wouter Joosen is a professor in the Department of Computer Science at the Katholieke Universiteit Leuven. His research interests include software architecture for distributed systems, aspect-oriented and component-based software development, adaptive middleware, security solutions, and secure software. Joosen received his PhD in computer science from K.U. Leuven. Contact him at DistriNet, Dept. of Computer Science, K.U. Leuven, Celestijnenlaan 200A, B-3001 Leuven, Belgium;
[email protected]. R e l a t e d
L i n k s
DS Online's Middleware Community "Label-Based Access Control Policy Enforcement and Management," Proceedings of SNPD 06 "Policy-Based Access Control Framework for Grid Computing," Proceedings of CCGRID 06
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.
IEEE Distributed Systems Online June 2006
13
Related Work on Access Control Technologies
Our research relates to a number of access control technologies for enforcing applicationspecific 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 concerns6 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.
IEEE Distributed Systems Online June 2006
14
References 1.
G. Karjoth, “Access Control with IBM Tivoli Access Manager,” ACM Trans. Information System Security, vol. 6, no. 2, 2003, pp. 232–257.
2.
K. Beznosov et 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.
3.
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.
4.
R. Monzillo, “Java Authorization Contract for Containers,” v.1.0, 2003; http://java.sun.com/j2ee/javaacc.
5.
G. Brose, “Manageable Access Control for CORBA,” J. Computer Security, vol. 10, no. 4, 2002, pp. 301–337.
6.
H. Ossher and P. Tarr, “Using Multidimensional Separation of Concerns to (Re)Shape Evolving Software,” Comm. ACM, vol. 44, no. 10, 2001, pp. 43–50.
7.
B. De Win, W. Joosen, and F. Piessens, “Developing Secure Applications through AspectOriented Programming,” Aspect-Oriented Software Development, E. Robert et al., eds., Addison-Wesley, 2005, pp. 633–650.
8.
E. Song et 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.
9.
Ú. Erlingsson, “The Inlined Reference Monitor Approach to Security Policy Enforcement,” doctoral thesis, Dept. of Computer Science, Cornell Univ., 2004.
IEEE Distributed Systems Online June 2006
15
