An Access Control Framework for Reflective Middleware - Springer Link

Huang G, Sun LS. An access control framework for reflective middleware. JOURNAL OF COMPUTER SCIENCE AND TECHNOLOGY 23(6): 895–904 Nov. 2008

An Access Control Framework for Reflective Middleware Gang Huang (黄罡) and Lian-Shan Sun (孙连山) Key Laboratory of High Confidence Software Technologies, Ministry of Education, Beijing 100871, China School of Electronics Engineering and Computer Science, Peking University, Beijing 100871, China E-mail: [email protected]; [email protected] Received July 5, 2007; revised July 17, 2008. Abstract Reflective middleware opens up the implementation details of middleware platform and applications at runtime for improving the adaptability of middleware-based systems. However, such openness brings new challenges to access control of the middleware-based systems. Some users can access the system via reflective entities, which sometimes cannot be protected by access control mechanisms of traditional middleware. To deliver high adaptability securely, reflective middleware should be equipped with proper access control mechanisms for potential access control holes induced by reflection. One reason of integrating these mechanisms in reflective middleware is that one goal of reflective middleware is to equip applications with reflection capabilities as transparent as possible. This paper studies how to design a reflective J2EE middleware — PKUAS with access control in mind. At first, a computation model of reflective system is built to identify all possible access control points induced by reflection. Then a set of access control mechanisms, including the wrapper of MBeans and a hierarchy of Java class loaders, are equipped for controlling the identified access control points. These mechanisms together with J2EE access control mechanism form the access control framework for PKUAS. The paper evaluates the security and the performance overheads of the framework in quality and quantity. Keywords

1

reflective middleware, access control, J2EE

Introduction

Nowadays, the extremely open and dynamic nature of Internet makes user requirements and operating environments change frequently. To help applications to survive in the sea of rapid and continuous changes, middleware, the popular software infrastructure over the Internet, has to provide much more adaptability than ever[1] . However, it is very hard, sometimes impossible, for traditional middleware platforms to support the adaptation because of the philosophy of “blackbox” reuse. To free the developers from dealing with the common problems in distributed systems, traditional middleware tries to hide implementation details as many as possible, which, at the same time, prevents maintainers from monitoring and adapting the applications for changes. In order to support adaptation, reflective middleware emerged as an extension to traditional middleware[1,2] . Compared to traditional middleware, reflective middleware makes runtime states and behaviors inside middleware platforms and applications observable and adaptable through inserting a set of

meta entities into traditional middleware, as shown in Fig.1. Maintainers can easily monitor and adapt the applications via these meta entities. However, along with the high adaptability delivered by the reflective middleware, new security challenges also emerged. In Fig.1, clients can access application entity via either the traditional middleware or meta entities that are inserted for reflection. Obviously, it is necessary to set proper access control for meta entities via which the application entities could be accessed by bypassing traditional middleware access control check. In this case, the additional complexity involved in delivering security becomes an obstacle to adopting reflective middleware for high adaptability. In particular, when different reflection capabilities developed by different vendors are

Fig.1. Overview of reflective middleware.

Regular Paper This work is supported by the National Basic Research 973 Program of China under Grant No. 2005CB321805, the National HighTech Research and Development 863 Program of China under Grant No. 2007AA010301, the National Natural Science Foundation of China under Grant No. 60528006 and the Fok Ying Tung Education Foundation.

896

J. Comput. Sci. & Technol., Nov. 2008, Vol.23, No.6

adopted, delivering security becomes much more challenging than ever. To help the developers to handle possible access control holes induced by reflection, reflective middleware should be equipped with proper access control mechanisms which can protect the reflective systems at least to the degree as the traditional middleware does for traditional systems. That is, reflection should not debase the security degree and usability promised by traditional middleware access control mechanisms. This paper presents the design and implementation of an access control framework for a reflective J2EE (Java 2 Platform Enterprise Edition) application server, called PKUAS (PeKing University Application Server)[3] . Our framework promises the same security degree and usability as those promised by J2EE access control service. In addition, our framework promises much lower performance overhead than those promised by the default Java security manager, which can be employed to control MBeans (the meta entities in PKUAS). The rest of this paper is organized as follows. Section 2 briefly introduces reflective systems. Section 3 builds up the reflective computation model and identifies the access control points in systems based on reflective J2EE compliant middleware. Section 4 presents the access control framework in PKUAS. Section 5 introduces how to use the framework. Section 6 evaluates its security qualitatively and performance overhead quantitatively. Section 7 discusses our work against related work. Section 8 concludes this paper and presents the future work. 2

Reflective Systems

Reflection, also known as computational reflection, is originated by B.C. Smith, which accesses and manipulates the LISP program as a set of data in execution[4] . Since it helps to achieve flexible and adaptive systems, reflection is propagated into operating system[5] , distributed system[6] and middleware[7] one by one. Fig.2 illustrates the fundamental concepts of reflection. A reflective system is a computational system with two levels. The base level consists of base entities that perform the usual functionalities of the system, that is, the basic capability of a computational system regardless of whether it is reflective or not. In detail, it builds a model to represent the problem domain and then reasons and manipulates the model to solve the problems. The meta level consists of meta entities that reflect the base level entities. It builds a model to represent the base level. This model, called self-representation of the system, is causally connected

with base entities, that is, changes of base entities will immediately lead to corresponding changes in selfrepresentation, and vice versa[8] . The computation in the meta level is to guarantee the causal connection between self-representation and base entities. Then, a reflective system can be formally defined as the computational system having the ability, called reflection, so that its internal states and behaviors can be accessed and modified through its causally connected selfrepresentation.

Fig.2. Technical model of reflective computing.

3 Access Control Points in Reflective J2EE As a common means of protecting the resources of information systems against unauthorized disclosure or modifications and, at the same time, ensuring their availability to legitimate users, the access control mediates every request to resources and determines whether the request should be granted or denied[9] . For the purpose of granting or denying a request, some points in applications should be equipped with proper access control mechanisms, such as authentication and authorization, which will check users’ credentials or authorization policies. These points are called access control points in this paper. Access control points are actually segments of applications, where proper access control mechanisms should be integrated. Access control points in PKUAS can be classified into two categories. One includes access control points in standard J2EE. The other includes access control points induced by reflection in PKUAS. In J2EE, as shown in Fig.3, when a client tries to

Fig.3. Access control in J2EE[10] .

Gang Huang et al.: An Access Control Framework for Reflective Middleware

access the protected resources maintained by the web container or EJB container, each container including access control points can integrate appropriate authentication and authorization mechanisms to check users’ credentials or authorization policies. In a standard J2EE application, a container consists of multiple sub-components for various tasks, such as dispatching invocations, hooking security service (access control point AC in Fig.4) or transaction service, or creating and destroying component instances etc. It is worth noticing that standard access control points in J2EE are placed before one or more base entities responsible for component instances management and other business-independent tasks.

Fig.4. Invocation paths in reflective middleware.

As shown in Fig.4, invocation paths to an application component in standard J2EE applications can be abstracted as: P 1 : Client/AE → EBE → BE n → AC → BE n → AE

(n > 0),

where access control point (AC ) appears in the middle of the path. After introducing EME and ME for reflection, client can access application components by bypassing standard access control points in J2EE via two patterns of invocation paths as follows.

4

897

Access Control Framework in PKUAS

In this section, we will discuss the design and implementation of the access control framework in PKUAS by which all the access control points induced by reflection are made controllable. First, we introduce briefly the PKUAS with an emphasis on how reflection is implemented. Then, we present how we reuse standard J2EE access control mechanism and J2SE class loading mechanism to manipulate the access control points induced by reflection. 4.1

Reflective Application Server — PKUAS

PKUAS is a J2EE-compliant application server, which is the platform including J2SE (supports the execution of Java programs), common services (supports functions common to network based systems, such as security, transaction and messaging), a Web Container (also called Web Server and supports JSPs and servlets that deal with human-computer interactions and simple business logic), and an EJB Container (supports EJBs that deal with business logic and business data)[3] . Currently, PKUAS is successfully used in many practical and commercial applications, including the virtual research center of Chinese Ministry of Education, the largest component library in China, the intelligent traffic control system in the city of Dalian, the web-based and integrated business supporting system in one of the biggest investment companies in China, the web sites of many Chinese universities, and so on. In order to identify entities to be reflected clearly and to manipulate a given entity independently from the others, PKUAS organizes its internal functions required by J2EE V1.3[10] and EJB V2.0[11] as several loose-coupled platform components, as shown in Fig.5.

P 2 : Client/AE → EME → ME m → BE n → AE

(m > 1, n > 0).

P 3 : Client/AE → EBE → BE n → ME m → BE n → AE

(m > 1, n > 0).

The two patterns introduce a set of new access control points to be considered when protecting reflective system. For example, the possible invocation Client/AE → EME implies that the access to the entry of meta entities should be controlled, and the possible invocations EME → ME m , ME m , and BE n → ME m imply that the access to meta entities should be controlled.

Fig.5. Componentized structure of PKUAS.

In Fig.5, a container provides a runtime space for the components in the deployed applications[10] . PKUAS implements standard EJB containers for stateless session beans, stateful session beans, bean-managed entity beans, container-managed entity beans, and message-driven beans[11] . One instance of a container holds all instances of one EJB. A container system consists of the instances of the containers holding all EJBs in an application. Such organization of the containers facilitates the configuration and management specific to

898


individual applications, such as the security realm per application and the architectural information of the application. A service provides one of the common functions, e.g., naming, communication, security, transaction, log and so on. A tool provides one of the functions that facilitates the operation of PKUAS, such as deployment and management. The micro kernel of PKUAS provides a registry and an invocation framework for meta entities. As shown in Fig.6, PKUAS has one base level, two meta levels and an entry allowing access from the outside of PKUAS.

Fig.6. Reflective framework in PKUAS.

The base level consists of platform components and the application components deployed onto PKUAS. Platform components that can be reflected in PKUAS include container system and various common services in J2EE. When business invocations (Client/AE ) for base level components arrive, the platform components and application components will collaborate with each other to deal with the invocations. Meta entities may be incarnated or activated in the process of dealing with business invocations① . When reflective invocations arrive (e.g., invocations of monitoring and adapting the systems), entities on two meta levels will collaborate with each other to deal with the invocations. The first meta level consists of meta entities that reflect base entities directly. For the purpose of providing fine-grained reflection, a base entity may be reflected by more than one meta entity. For example, the communication service is very complex, and has multiple meta entities to reflect the communication acceptors, communication connectors and communication transporters respectively. Meta entities in the first meta level are so closely coupled with base entities because their vendors have to know the implementation details of base entities for incarnation. Considering the communication service again, the fine-grained reflection can be achieved only when the vendor of meta entities understands how the communication service is constructed and which parts can be monitored or/and changed at runtime.

The first meta level usually consists of irrelative entities, which are necessary but insufficient for users to monitor and adapt reflective system in an easy-to-use way. Therefore, PKUAS provides the second-level meta entities that make the observation and manipulation based on reflection more understandable and usable. As shown in Fig.6, meta entities in the second meta level reflect and reify the base entities by operating the meta entities at the first meta level. Currently, the meta entities in the second meta level of PKUAS compose multiple views of software architecture[3] and the standard J2EE management view[12] , which are easier to use for users. The second-level meta entities also perform some self-operations, such as self-healing for failures and self-optimizing for better performance[13] . In fact, the third parties can enrich the meta entities in the second levels without knowing the implementation details of the base-level entities. 4.2

Handling Invocations to the Entry of Meta Entities (Client → EME).

A client may access critical meta entities through the entry of meta entities (EME), which may be the most distinct security threat induced by reflection. It requires the access control of any requests to EME. In PKUAS, the entry of meta entities is implemented as a stateless session EJB, called MEJB. As an EJB, MEJB can be directly protected by the standard J2EE access control mechanism. Acting as a gateway to the meta entities and in order to conform to the J2EE management specification[12] , MEJB only provides a set of general-purpose methods, such as “setAttribute” and “getAttribute” for setting and getting the given attribute of a meta entity and “invoke” for invoking the given method of a meta entity[13] . As a result, the standard J2EE access control on MEJB cannot control accesses to the different meta entities according to different policies. That is to say, meta entities should be equipped with access control mechanisms even though the entry to them can be controlled by standard J2EE access control mechanism. 4.3

Handling Invocations to Meta Entities (BE n → ME m , ME m , and EME → ME m )

A meta entity can be invoked by base entities, other meta entities, or by the entry of meta entities. When meta entities are called directly or indirectly by base entities corresponding to business invocations, invocations to them should be controlled according to access

① Note that the whole system will work well without meta entities and the micro kernel does not participate in the process of business invocations.


control policies for business invocations. When meta entities are called directly or indirectly by EME corresponding to reflection invocations, invocations to them should also be controlled according to user-defined access control policies about who can monitor or adapt the system. In both cases, any invocations to the meta entities should be controllable. That is to say, some access control mechanisms should be equipped by vendor of reflective middleware, and access control policies should be defined by application developers, on granting or denying that some users access meta entities. In PKUAS, all the meta entities are implemented as MBeans defined in JMX specification[14] . There are two ways to enforce access control between MBeans. The first way is to use the standard JMX access control. JMX defines a set of Java permissions specific to MBeans, including the “MBeanServerPermission” for controlling access to the static methods of the class javax.management.MBeanServerFactory, the “MBeanPermission” for controlling access to the methods of MBeanServer, and the “MBeanTrustPermission” for identifying the trust signer or code source for MBeans. At runtime, JMX uses Java security manager to control the invocations between MBeans according to the permissions. The standard JMX access control has two disadvantages. First, it will put an unendurable impact on the performance of business transactions because Java security manager checks any access appearing in Java Virtual Machine, which decreases the performance of the whole Java program by 13%∼14%[15] . Second, the specification of security policies is much more complex than that specified in the J2EE deployment descriptor. Administrators have to study two different tools and to deal with implicit dependencies between different policies. Then, PKUAS implements a new access control mechanism for MBeans. We implement a wrapper for the standard MBeanServer, which is the registry and invocation framework for MBeans. The wrapper reuses the implementation and security policy of the standard J2EE access control to control the access between MBeans, just like the access control mechanism between the clients and MEJB. The wrapper is actually a container for MBeans. Like standard containers in J2EE, the wrapper can also employ proper authentication and authorization mechanisms to perform access control and can propagate principals of callers to callees to avoid duplicated authentication. 4.4

including the application entities, in a reflective system. This is actually the source of security threats induced by reflection. Although access control mechanisms equipped at both the entry of meta entities and meta entity itself can protect the reflective interfaces from unauthorized access, it is valuable to regulate which meta entities can access which base entities for saving the efforts of developers in defining access control policies for different access paths. Unlike the above two classical access control mechanisms, PKUAS employs the class loading mechanism, a distinguished feature of Java language, as a special mechanism to ensure that only the meta entities directly reflecting a base entity can access this base entity without the micro kernel. In other words, if other meta entities want to reflect the base entity, they have to access the meta entities directly reflecting the base entity through the micro kernel, which will control this access. In PKUAS, these meta entities are categorized into the second meta level and they reflect the base system via meta entities in the first meta level. In Java, class loaders are responsible for loading class definitions from the “.class” files[16] . The classes loaded by the same class loader can access each other directly, while the classes loaded by different class loaders cannot access each other directly. Naturally, loading the base entity and the meta entities directly reflecting it with the same class loader and loading different base entities and other meta entities with different class loaders can meet the requirements of the access control between meta entities and base entities. However, Java Virtual Machine provides only one class loader in default. The default class loader only loads classes from the directories or “.jar” files specified by the “java.class.path” property of Java Virtual Machine and does not reload the class definition with the same name of an already loaded class. Furthermore, it cannot support the replacement of classes required by reflection. Then PKUAS implements a set of class loaders that constitute a hierarchy as shown in Fig.7. Being the top of the hierarchy, System Class Loader is responsible for loading the common classes required

Handling Invocations from Meta Entity to Base Entity (ME m → BE n → AE)

In theory, a meta entity can reflect any base entity,

899

Fig.7. PKUAS class loader hierarchy.

900

by the implementations of PKUAS and applications, such as the classes provided by J2SE, the classes for XML parser. These classes are visible to all other classes in PKUAS and cannot be replaced at runtime. The second layer consists of four types of “brother” class loaders. Service Class Loader is responsible for loading classes specific to one service, e.g., security service, transaction service and communication service; EJB Application Class Loader is responsible for loading classes from the “.ear” or “.jar” file that contains EJB implementations; and Web Application Class Loader is responsible for loading classes from the “.ear” or “.war” file that contains JSP/Servlet and other web pages. Meta Entity Class Loader is responsible for loading classes specific to a set of meta entities that do not directly reflect base entities and can access each other directly. If the meta entities are prohibited to access each other directly because, they are implemented by different vendors, they will be loaded by different instances of Meta Entity Class Loader. The “brother” relationship ensures the services, EJB applications and Web applications, and meta entities cannot access each other without the help of PKUAS micro kernel. EJB Application Class Loader will create an EJB Class Loaders per EJBs, and EJB Class Loader will create three class loaders to load the contract, implementation and constraints respectively. Service Class Loader may create the similar sub-tree. The meta entities directly reflecting base entities will be loaded by the class loader of their reflecting base entities if all of the classes are deployed into one package. For example, the “CustomerMBean” is loaded by the EJB Class Loader of “Customer”, and the “CustomerImplementationMBean” is loaded by the class loader of “CustomerImplementation”. There has a “parent” relationship between two class loaders in different layers, e.g., System Class Loader is the parent of all other class loaders, and EJB Class Loader is the parent of EJB Contract/Implementation/Constraint Class Loaders. This relationship ensures that the classes loaded by a class loader directly access the classes loaded by the parent class loader, and not vice versa. Since the hierarchy is defined in terms of the contained relationship between base entities, it implies that if a meta or base entity (called M ) contains another meta or base entity (called N ), the role that can access M can also access N , but not vice versa. For example, the “CustomerImplementationMBean” can directly access the “CustomerMBean”. Such implication puts a little impact on the specification of security policy because it only exists among the trustworthy meta entities that directly reflect base entities.


5

Using the Framework

Role-based access control requires the specification of security policy, that is, which role can access which resources. In J2EE, the resources to protect are mainly EJBs because EJBs provide the main business functions required by the clients. For reflective J2EE, the resources to protect are not only EJBs but also meta entities implemented as MBeans because the meta entities provide the main reflection functions required by the clients. For the system based on PKUAS, the developers and the deployers of the business components are responsible for specifying the security policies for EJBs, while the developers and the deployers of meta entities are responsible for specifying the security policies for meta entities. In order to facilitate the specification of security policy for reflection, we reuse the standard specification tool of J2EE security policy, that is, the XML-based deployment descriptor. J2EE security policy consists of a set of security roles and method permissions[10,11] . A security role is a semantic grouping of permissions that a given type of users of an application must have in order to use the application successfully. Method permission is a permission to invoke a specified group of methods of the enterprise beans’ home and component interfaces. As shown in Fig.8, the deployment descriptor of Customer EJB specifies that only the role of “CustomerManager” can invoke the method of “setName”. It also implies that other methods of Customer EJB can be invoked by any role. Like the security policy on EJBs, the security policy on meta entities can be specified in the deployment descriptor of meta entities. As shown in Fig.8, the deployment descriptor of RSAMBean specifies that only the role of “ApplicationManager” can invoke all the methods, identified as “∗”, of RSAMBean, which is a highlevel meta entity for monitoring and changing an application from the perspective of software architecture[17] . Sometimes, the security policy on both business invocations and reflection invocations may have some implicit relationships or dependencies. For example, the business methods of an EJB can be invoked through the business request or reflection request, e.g., the business methods of Customer EJB can be invoked through the “invokeBusiness” method of CustomerMBean, which directly reflects the Customer EJB. Though different requests will be checked by different access control mechanisms, both of them may use the same security policies. In other words, the business request and the reflection request should be equipped with one of the roles that


can access the EJB. As shown in Fig.8, the deployment descriptor of CustomerMBean specifies that only the role of “CustomerManager” can invoke the method of “invokeBusiness” with the “setName” value of the “methodName” parameter. Recalling the security policy on Customer EJB, we specify that only the role of “CustomerManager” can set the name of “Customer” through the business invocation and reflection invocation.

on PKUAS can control access to the systems easily by declaring proper access control policies in deployment descriptor as Section 5 does. In that, the usability of our framework is also the same as that of traditional J2EE access control service. Table 1. Access Control Mechanisms in PKUAS Path Mechanisms P1 AC for EJB P2 AC for EJB, AC for MBean, Classloading P3 AC for EJB, AC for MBean, Classloading Note: AC is the standard J2EE access control mechanism. AC for EJB is J2EE security service employed by EJB containers; AC for MBean is J2EE security service employed by a customized wrapper of MBeans in PKUAS. Classloading is a meta entity which can only reflect directly base entities loaded by the class loader used for loading the meta entity.

6.2

Fig.8. Sample security policy.

6 6.1

Evaluation Security Evaluation

In this subsection, we evaluate whether all possible paths identified in Section 3, via which sensitive resources in reflective systems can be accessed, can be protected by proper access control mechanisms introduced in Section 4. Table 1 summarizes the access control mechanisms that can be employed to control accesses to the application components, via paths 1∼3 identified in Section 3. We argue that by reusing the standard J2EE access control mechanisms, developing wrapper for MBeans, and defining a hierarchy of class loaders, the access control framework in PKUAS can achieve the security degree the same as that in traditional J2EE application server. Developers of reflective systems based

901

Performance Evaluation

Definitely, the framework will put a performance overhead to the whole system. This section will evaluate two tests, running on a PC with P4 2.8GHz, 512MB SDRAM and Windows XP Professional, to investigate whether the performance overhead is reasonable and acceptable in practice. The first test is to compare the time consumed by obtaining the meta entities of the deployed applications, that is, to invoke the “queryNames” method of “MBeanServer” when not deploying access control, when using the access control between client and the entry of meta entities, and when using the access control between the meta entities respectively. There are 100 method permissions. As shown in Fig.9, the 10 000 invocations spend 39, 92.1 and 96.9 milliseconds respectively. The result proves that the access control mechanisms did put a performance penalty on the whole system and the two access control mechanisms spent similar time due to they used similar mechanisms.

Fig.9. Comparison of response time.

The performance overhead induced by the framework is acceptable in practice because access control will be executed only once in a session of handling refection invocation. Though some meta entities will be

902


activated in the business invocation, most of them are such meta entities that directly reflect base entities and then do not activate the access control mechanisms. In fact, PKUAS will build a hash map to record the meta entities that need no access control and then will skip them when possible. The second test is to investigate the performance overhead induced by the hierarchy of class loaders. There are two classes, Class A invokes Class B, and three class loaders, Class Loader M is the parent of Class Loader N and N is the parent of Class Loader L. A will invoke B in three conditions. The first condition is that L loads both classes, which simulates the invocation between classes loaded by the same class loader. The second condition and the third condition are that L loads A, and either N or M loads B, which simulates the invocation between the classes loaded by the parentson class loaders. The time spent in 100 invocations in the three conditions is 25, 27.2, 28.3 milliseconds respectively. (They are much longer than the time in the first test mainly because the class loaders are activated 100 times in the second test to make the performance overhead induced by class loaders observable, while the class loader is activated only once in the first test.) It reveals that the hierarchy puts a very little impact on the invocations between classes. We also test the time for initializing the three conditions, including creating class loaders and loading classes. They are 21.9, 25 and 29.6 milliseconds respectively. The difference is mainly due to the number of class loaders. It reveals that the hierarchy of class loaders puts a little impact on the initialization of the application. 7 7.1

Discussion and Related Work Discussion

In fact, access control is only one alternative for confidentiality and integrity in information security of middleware-based systems. This paper just tries to provide reflective J2EE application server with the same degree of security as that of standard J2EE application server. We try to do this because reflective middleware is actually an extension to traditional middleware. Users of reflective middleware will tacitly expect better or at least the same degree of security. To achieve this goal, our framework reuses the standard J2EE middleware security service and the Java class loading mechanism to control all access paths introduced by reflection. In addition, compared to Java default security manager, which also can be used to control access to meta entities (the MBeans) in PKUAS, our framework introduces much lower performance overhead. To make our framework work correctly, some

pre-conditions and post-conditions should be hold. First, sometimes, local resources, such as files, threads and sockets, are so important to protect in Java. A hostile meta entity can exhaust these local resources to crash the whole system. So, it is necessary to authenticate meta entities before integrating them into PKUAS. For now, PKUAS excludes potential hostile meta entities by the access control of PKUAS naming service. That is, only meta entities having right identity and password can register themselves into PKUAS. Second, adding capabilities of reflection into traditional middleware is to insert meta entities into it and to construct casual connections between the meta entities and the base entities properly. The meta entities can be reflected by the higher-level meta entities. Multiple levels of meta entities form a reflective tower. Different level of the meta entities may be implemented by different technologies. Whenever new meta entities implemented by different vendors with different technologies are inserted into the middleware, the developers or the deployers of them should consider whether these meta entities will introduce new access control holes via which unauthorized users can access sensitive resources, and how to make these holes controllable by proper access control mechanisms. For example, in PKUAS, the meta entities are implemented as MBeans conforming to the JMX specification, which is just one alternative of the design and the implementation of reflective middleware. In fact, the meta entities can also be implemented as EJBs, and for which, standard J2EE access control mechanism is sufficient. In short, the access control framework for the reflective middleware depends on the way of designing and implementing the reflective middleware. Third, obviously, the meta entities developed by the third parties (not the vendor of the base middleware) should not be allowed to reflect the base entities directly. In that, reflective middleware should provide API for third parties to build customized reflective entities to reflect content in specific theme. For example, for a specific application on PKUAS, composed of components developed by different vendors, the developers may deploy a reflective entity to reflect all the output calls issued by components from a specific vendor to monitor their conformance to security declaration. 7.2

Related Work

The first Workshop on Reflection and Meta Level Architectures in 1990[19] already recognized that reflection brings new security threats, which should be seriously controlled. However, the research and practice mainly focus on the implementation and


application of reflection and pay little attention to the security problem. For example, in the past several years, many reflective middleware have been developed as an extension to the common middleware. DynamicTAO[20] , OpenCORBA[7] and FlexiNET[21] are reflective CORBA (Common Object Request Broker Architecture) platforms. mChaRM[22] is a reflective RMI (Remote Method Invocation) platform. mChaRM recognizes a weak point of security induced by objectbased reflective computation model and provides a communication reification-based approach to curing it. OpenORB[2] adds reflection ability into COM (Component Object Model). JBoss[23] is a reflective J2EE application server. All of these researches focus on the implementation of reflection but pay little attention to the security issues. Guarana[24] improved the reflective capability of Java via modifying the Java Virtual Machine. It provided a meta entity, called composer, to reconfigure other meta entities and their reflective relationships with base entities. The composer is the unique point via which the meta entities can access the base entities. Caromel et al. defined a set of Java permissions specific to the base entities and use Java security manager to control the access between the meta entities and the base entities[15] , which suffers the 13%∼14% performance overhead. As mentioned in the section about the access control mechanism between the meta entities, the standard JMX access control suffers the same performance overhead as that of Caromel et al. and cannot be seamlessly integrated with the standard J2EE access control. Compared to these work, we study a much more complex reflective middleware system, and pay more attention to access control for the meta entities. Besides introducing additional security threats into systems, reflection, sometimes, can be used to enforce access control. For example, Welch[25] developed a reflective Java, called KAVA, and used it to enforce access control policies upon user-level compiled code. Actually, KAVA can be used as a replacement for standard J2EE access control service to enforce arbitrary access control rules rather than only role-based ones that are enforced by J2EE access control service. However, KAVA achieved the flexibility at the cost of simplicity of defining access control rules and reasoning on their correctness. When loaded, any Java classes in bytecode can be decorated with proper enforcement code in corresponding meta objects according to binding specifications. In contrast, our framework aims at eliminating security threats introduced by reflection while retaining the benefits of J2EE security. We achieve this by complementing the standard J2EE access control service to

903

control all the access paths introduced by reflection. 8

Conclusion and Future Work

Though improving the adaptability of middleware, reflection brings new security threats. This paper studies the damage to access control, and succeeds in eliminating of the damage by providing a novel access control framework. By our framework, the developers or deployers of meta entities can declare access control policies, for the meta entities as they do for normal EJB. Consequently, the complexity of configuring the meta entities is the same as that of configuring EJB because our framework implements access control mechanisms for the meta entities by reusing standard J2EE access control service for EJB. Due to the same reason, our framework can only support policies conforming to core role-based access control model, which is enabled by standard J2EE access control service, while other access control policies, such as those related to temporal conditions, content related conditions, cannot be processed by our framework. Compared to Java default security manager, our framework promises much lower performance overhead. Like standard J2EE access control service, our framework achieves this at the cost of flexibility. That is, our framework cannot support access control policies related to temporal conditions and other conditions. The future work will focus on the practical application of the framework for optimization and the visual tool for reducing the complexity and cost of analyzing and specifying access control policies. In fact, correct specification of access control policies is the key to make the framework work. The XML-based deployment descriptor only provides a basic tool for specifying the access control policy. The specification of access control policy is still a complex, difficult, time-consumed, tired and error-prone work, which implies that a visual tool is necessary. PKUAS provides a visual deployment tool[18] for specifying the standard J2EE access control policy. The tool can be extended so that it can specify the access control policy for reflection. Besides the visual facilities, the developers need more automatic support in generating access control policies in XML-based deployment descriptor and ensuring their quality due to various reasons, for example, the complexity of handling voluminous interactional access control policies defined for different component methods and the inevitably ad hoc mistakes induced by human. We are working on this point and have provided some achievements, including a transformation engine[26] and a validation engine[27] to generate access

904

control policies from access control requirements and ensuring their quality respectively. Although promising, these achievements are still in the infancy and need to be enhanced in working with weaker assumptions and in changeful settings. In fact, access control is not enough to secure the whole system. J2EE employs other access control policies and mechanisms, such as location-based authentication and secure socket layer[10] . We plan to explore the impact of reflection on other security mechanisms in the future.


[18]

[19]

[20]

References [1] Agha G (ed.). Special Issue on Adaptive Middleware. Communications of ACM, 2002, 45(6): 30–64. [2] Blair G S, Coulson G et al. The design and implementation of open ORB 2. IEEE Distributed Systems Online, 2001, 2(6): 1–40. [3] Mei H, Huang G. PKUAS: An architecture-based reflective component operating platform (invited paper). In Proc. the 10th IEEE Int. Workshop on Future Trends of Distributed Computing Systems, Kawada S (ed.), Suzhou, IEEE Computer Society, 2004, pp.163–169. [4] Smith B C. Procedural reflection in programming languages [Dissertation]. MIT, 1982. [5] Yokote Y. The apertos reflective operating system: The concept and its implementation. In Proc. Conference on ObjectOriented Programming Systems Languages and Applications (OOPSLA’92), Vancouver, Canada, ACM SIGPLAN Notices, ACM Press, 1992, 27(10): 414–434. [6] McAffer J. The CodA MOP. In Proc. Workshop on ObjectOriented Reflection and Metalevel Architectures, Washington DC, USA, 1993. ACM. [7] Ledoux T. OpenCorba: A reflective open broker. In Proc. the 2nd International Conference on Reflection, Saint-Malo, France, LNCS 1616, Heidelberg: Springer-Verlag, 1999, pp.197–214. [8] Maes P. Concepts and experiments in computational reflection. In Proc. ACM Conference on Object-Oriented Programming, Systems, Languages and Applications (OOPSLA’87), Orlando, FL, USA, October 1987, pp.147–155. [9] Vimercatil S, Paraboschi S, Samaratil P. Access control: Principles and solutions. Software Practice and Experience, 2003, 33(5): 397–421. [10] Java 2 Platform Enterprise Edition Specification. Version 1.3, SUN Microsystems, 2001. [11] Enterprise JavaBeans Specification. Version 2.0, SUN Microsystems, 2001. [12] Java 2 Platform, Enterprise Edition Management Specification. Sun Microsystems, 2002. [13] Huang G, Liu T C, Mei H, Zheng Z Z, Liu Z, Fan G. Towards autonomic computing middleware via reflection. In Proc. COMPSAC 2004, Hong Kong, China, pp.122–127. [14] JavaTM Management Extensions Instrumentation and Agent Specification. v1.4, Sun Microsystems, 2006. [15] Caromel D, Vayssiere J. A security framework for reflective Java applications. Software Practice and Experience, 2003, 33(9): 821–846. [16] Gosling J, Joy B, Steele G, Bracha G. The Java Language Specification. Second Edition, SUN, 2000. [17] Huang G, Mei H, Yang F Q. Runtime recovery and manipulation of software architecture of component-based systems.

[21]

[22]

[23]

[24]

[25]

[26]

[27]

International Journal of Automated Software Engineering, Springer, 2006, 13(2): 257–281. Lan L, Huang G, Ma L, Wang M, Mei H, Zhang L, Chen Y. Architecture based deployment of large-scale component based systems: The tool and principles. In Proc. 8th International SIGSOFT Symposium on Component-Based Software Engineering (CBSE), St. Louis, USA, 2005, LNCS 3489, Springer, pp.123–138. Ibrahim M H (ed.). Report of the First Workshop on Reflection and Metalevel Architectures in Object-Oriented Programming. OOPSLA/ECOOP, Ottawa, Canada, 1990. Kon F, Roman M, Liu P, Mao J, Yamane T, Magalhaes L C, Campbell R H. Monitoring, security, and dynamic configuration with the dynamicTAO reflective ORB. In Proc. IFIP/ACM International Conference on Distributed Systems Platforms and Open Distributed Processing, New York, USA, LNCS 1795, Sventek J, Coulson G (eds.), Springer-Verlag, 2000, pp.121–143. Hayton R, Team A. FlexiNet architecture. Citrix Systems (Cambridge) Limited, Architecture raport, Technical Report, 1999. Cazzola W. Communication-oriented reflection: A way to open up the RMI mechanism [Dissertation]. Universit ` adegli Studi di Milano, Milano, Italy, 2001. Fleury M, Reverbel F. The JBoss extensible server. In Proc. IFIP/ACM Middleware’03, Rio de Janeiro, Brazil, LNCS 2672, Endler M, Schmidt D C (eds.), Springer-Verlag, 2003, pp.344–373. Oliva A, Buzato L E. The design and implementation of Guaran´ a. In Proc. the 5th Conference on USENIX Conference on Object-Oriented Technologies & Systems, Volume 5, San Diego, California, USA, 1999, pp.121–143. Welch I. Using load-time metaobject protocol to enforce access control policies upon user-level compiled code [Dissertation]. Univ. of Newcastle-Upon-Tyne, 2004. Sun L, Huang G, Sun Y et al. An approach for generation of J2EE access control configurations from requirements specification. In Proc. the 8th International Conference on Quality Software, Oxford, UK, August 12–13, 2008, pp.87–96. Sun L, Huang G, Mei H. Validating access control configurations in J2EE applications. In Proc. the 11th International Symposium on Component Based Software Engineering (CBSE-2008), Karlsruhe, Germany, October 14–17, 2008.

Gang Huang is an associate professor in the School of Electronics Engineering and Computer Science, Peking University. His research interests are in the area of distributed computing with a focus on middleware, including the construction and management of middleware, and software engineering with a focus on component based development and software architecture. Lian-Shan Sun is a Ph.D. candidate in the School of Electronics Engineering and Computer Science, Peking University. His research interests are in the area of software architecture and componentbased software development, with a focus on quality attributes related issues, in particular, the security.