, Fraunhofer FOKUS
Abstract—Integrating CORBA component-based and model-driven middleware and a policy management framework simplifies defining, managing, and enforcing security policies.
Enforcing appropriate security policies in distributed, component-based applications is difficult. In many cases, the security functionality of standard middleware such as CORBA or Enterprise JavaBeans doesn't adequately protect an application and its resources. The common solution to this problem is to directly implement security enforcement in the application source code.
Although this approach is flexible, it has several serious problems. First, it requires the application components' designers and implementers to also be security specialists, which is rare in real life. Sometimes developers also don't know in what environment the component will be used, so they can't define an appropriate security policy. So, programmers often simply ignore security. Second, this approach couples functional and nonfunctional aspects, hindering component reusability. A component can only be reused if the functional and nonfunctional requirements match. Developers must therefore clearly separate an application's functional and nonfunctional parts. The functional parts—that is, the business code—are implemented in a component. The nonfunctional parts, such as the security policy's enforcement, must be defined by a separate policy and enforced by the component's runtime infrastructure.
While this sounds good in theory, it's hard to do. A generic framework to define and evaluate security policies is necessary, and that framework must be integrated with the middleware platform. The middleware must provide the necessary hooks to intercept calls and obtain the information required for security enforcement. We designed and developed a security framework, integrated it into the CORBA Component Model 1 middleware platform, and evaluated it in a real-world project.
CCM is one of the best platforms for developing large-scale distributed systems. It's based on the mature CORBA middleware 2 and includes several more advanced concepts. It also simplifies the use of CORBA services.
CCM enhances the CORBA object model. Figure 1 depicts a CORBA component's features. A component has a special interface (equivalent interface) that provides operations for introspection and navigation regarding other component features. A component can provide a set of facets, which are named ports providing specific interfaces. This component's clients call operations on a facet. The facet's counterpart, a receptacle, is a named port to which a specific interface can be connected. A facet of a CORBA component in a server role can be connected to a receptacle of a CORBA component in a client role. Receptacle ports make dependencies to other interfaces explicit, which helps minimize wrong configurations and runtime failures by providing type safety. As facets and receptacles are a means for operational interactions, event sources and event sinks are a means for asynchronous interaction. An event source can publish or emit events of a certain type. Event sinks can consume events of a certain type. Finally, the Object Management Group (OMG) has introduced a similar port concept for continuous interactions (that is, data streams) to CCM. A stream source port produces streams of a specific type of data, and a stream sink port receives such data. Attributes can be used to configure an instance of a CORBA component.
Figure 1 Object model of the CORBA Component Model.
CCM defines the container as a CORBA component's runtime environment (see figure 2). It includes the context interface, which provides access to the underlying platform services (such as CORBA services) as well as access to the component's application environment (such as connected interfaces at receptacle ports). Furthermore, the component implementation provides a callback interface to the container, which in turn manages the component implementation's life cycle. In the container also resides a home, an implementation of factory and finder patterns for managing component instances.
Figure 2 A CORBA component's container.
In previous research, we established that the CORBA Security Services specification doesn't meet the requirements of complex, distributed systems. 3,4 To overcome CORBA security's limitations for CCM-based applications, we developed the OpenPMF policy management framework ( http://www.openpmf.org) to define, manage, and enforce security policies in distributed systems. Although this article focuses on our CCM middleware platform, we designed OpenPMF to protect other platforms and applications as well.
OpenPMF is based on an abstract model of middleware security policies, defined in UML. From the abstract model, we generated a policy repository to store concrete instantiations of security policies. Rich policies are defined in a consolidated way using a policy description language (a PDL example excerpt is available elsewhere 5). The policies are fed into the repository using a PDL compiler. At startup or during policy updates, the application's security agents, called Policy Enforcement Points (PEP), obtain the policy from the repository and instantiate it. During runtime, the security agents intercept the invocations and evaluate the policy on the basis of the invocation's context. If the policy doesn't allow the invocation, the invocation is aborted and an exception is raised.
In this article, we only briefly cover issues related to assurance, such as how we ensure that the policy is correctly enforced or how the security framework's integrity is protected. We also don't discuss the principal limitations of security enforcement at the middleware level. We aim for access control on invocations at the middleware level. This is important in secure distributed systems, but the PEP and application developers must consider many other issues when developing and operating such systems. For example, the PEP developers must ensure that attacks at another level can't circumvent the middleware-level protection.
An important point in adaptive and reflective systems is the context description. The context gives information about the invocation or the environment, and the policy evaluator uses it to make decisions. It consists of information describing the system's functional and nonfunctional aspects. Functional information, for example, includes the call's target and the operation to invoke, which are both directly associated with an invocation. Nonfunctional information is, in many cases, also directly associated with an invocation (for example, the client's credentials); in other cases, it describes the environment independently of individual invocations (for example, time or position).
One of the biggest issues in describing and processing context information is the lack of standardization of its format and semantics, mainly because it describes different information from different sources. Defining a standard, orthogonal format for the context is therefore difficult. If the format is well defined and restrictive, the policy evaluator can handle it in a standard manner, but it can only express limited information. If, on the other hand, the format is flexible—for example, a buffer—it can express diverse information, but it's difficult to process uniformly. Another point to consider, apart from the data itself, is the description of the type of information .
The policy evaluator obtains context information from different sources. For example, the underlying security mechanism provides the client's credentials, and the middleware platform must provide the invocation target and operation. This greatly complicates obtaining the context information.
The different sources and formats of context information make processing it in policy management frameworks difficult because foreseeing all possibilities in the policy evaluator is impossible. In OpenPMF, we developed an orthogonal approach for handling context information called transformers.
Transformers provide a uniform interface to the underlying data sources. To obtain data from different sources, the policy evaluator now can call the same function, whether the data comes from the middleware, the security mechanisms, or another source.
A standard interface to context information doesn't solve the problem of the information format and semantics. The policy evaluator still doesn't know how to process this information—for example, how to compare the data. We solved this issue by moving the processing to the transformer itself, because the transformer knows the data it processes. Instead of letting the policy evaluator obtain the information from the transformer and compare it by itself with a selector from the policy, the policy evaluator just calls the transformer's compare function with the selector as an argument. The transformers obtain the context information automatically during the comparison.
The transformer abstracts from all peculiarities of the underlying platforms, data sources, data formats, and semantics. This greatly simplifies policy evaluation and increases OpenPMF's flexibility.
Most security systems define security policies as access control lists or by using policy definition languages like Ponder. The language is a central aspect of such systems.
Our policy management framework uses a different approach. The central aspect isn't the language but the policy's abstract information model—the metapolicy. This metapolicy provides an abstract way to describe policies, completely independent from how the policy is expressed (for example, in a file). We used the OMG's Meta-Object Facility (MOF) 6 and defined the metapolicy as a UML model. Our metamodel is flexible and describes in a consolidated, unified way how to express policy hierarchies, rules, and the entities used for the rule definitions (for example, initiators, clients, targets, and operations). This also allows the handling and definition of security policies based on different security models such as discretionary access control, 7 mandatory access control, 8 or role-based access control 9 by mapping the high-level security policies to the metapolicy's low-level rules.
From the metapolicy, the MOF toolkit generates a CORBA-based policy repository. The OMG MOF standard defines the model's mapping to the IDL (interface definition language) interfaces. The metapolicy and the repository derived from it don't solve the problem of how to define a policy. For this purpose, we developed a simple PDL that can describe policy hierarchies and policy rules. In contrast to common trends, we don't use XML for the policy description because we initially intended to write the policy manually. The next version of OpenPMF will use the PDL only as an internal representation for the GUI and will support XML. The policy, expressed in a PDL text file, is compiled and loaded into the policy repository. It's also possible to generate a PDL file from the policy in the repository or to visualize its logical structure.
We can assure the overall security framework by protecting the policy repository. Using OpenPMF to protect the repository is impossible; it would just generate a recursion. So, we hard-coded the access control for the repository in the repository code itself, and we bootstrapped the secure loading of policies via command line arguments.
Policy evaluators enforce the policies and are integrated into the middleware's call chain; for example, in CORBA they're called by portable interceptors (PIs) and in components by container portable interceptors (COPIs). At startup, the policy evaluator registers itself with a central management daemon, obtains the security policy from the policy repository, and instantiates it in an efficient, compact internal representation. After initialization, the policy evaluator is automatically called for all invocations. It iterates through the internal policy representation and calls the transformers associated with the entities in the rules (for example, to check the client's identity). When the evaluator finds a matching rule, it triggers the appropriate action. In most cases, this means that the invocation is allowed. If no match is found, the invocation is denied by default, an exception is raised, and a predefined operation can be called. You can use the policy evaluator at both the client and the server side of an invocation, depending on the security policy to enforce.
An important aspect of secure distributed systems is runtime monitoring. OpenPMF uses a central monitoring system. All events generated by the policy evaluators are sent to a central administrator console, where the administrator can take appropriate action. The management console also provides runtime management of the security policies and their enforcement (that is, it's possible to update security at runtime).
Metapolicies, model-based and adaptive policy definition, and enforcement are powerful techniques for developing secure, complex distributed systems. But they're difficult to implement in practice if the underlying middleware doesn't support sufficient interfaces for obtaining context information or modifying calls. As we described earlier, this issue makes access control at the middleware level in CORBA difficult. During middleware development, therefore, you must analyze how to provide the necessary hooks. The hooks (COPIs) are the result of close cooperation between the container developers and the developers of the adaptive security architecture, who require these hooks to have specific features to integrate security.
As we outlined earlier, when evaluating and enforcing security policies, it's crucial to have access to the context—in particular, to the call chain. It's important to have the hooks for putting a security policy in place. The required ability to intercept the call chain (which isn't unique to security policy integration) led to the definition of PIs as part of the CORBA specification. 2 PIs work on unmarshaled messages. This implies that they can't be used for message encryption. Secure transport connections such as SSL (Secure Sockets Layer) can be used instead.
The CORBA specification defines interfaces for the interceptors and for registering them with the ORB. A number of interception points are defined and are called at specific points in the call chain. Those interception points are also divided into client-side and server-side interception points. Figure 3 gives an overview of the CORBA interception points.
Figure 3 Interception points of CORBA portable interceptors.
With CCM's definition, the CORBA PIs can't be easily used for hooking user-dependent code into the application logic. This is because the PI specification requires the registration of interceptors as part of the ORB's initialization. The container initializes the ORB and completely manages the CORBA call chain. Even worse, the ORB creation occurs before any user-dependent code gets loaded into the container.
Two strategies let us overcome this issue: we can add proprietary extensions to the container or adapt the PIs to the CCM. We follow the second strategy. With our participating partners' help, we created a draft definition of the COPI, which the Coach project ( http://coach.objectweb.org) initiated. The resulting definition is undergoing standardization, and other companies support it as well. 10
COPI definition has two main goals. The first is to allow the smooth transformation of PI-based CORBA applications to CORBA component-based applications. This means that, similar to migration from CORBA to CCM, easy migration from PI to COPI should be possible. The second goal is to extend PI concepts to provide more flexibility than plain CORBA PIs provide. CORBA PIs can't modify the call chain, a fundamental design feature that renders them unusable for flexible, adaptive system architecture. They can only monitor a call, abandon a call, or use the forward-location exception to modify a call's target. PIs also can't modify operation parameters.
To achieve both goals while not putting too many constraints on container vendors, we separated the COPIs into two parts. The basic part covers the same functionality as the plain CORBA PIs; the extended part offers additional functionality for modifying requests.
Because basic COPIs are designed to migrate PI code to the component level, COPI interception points should be called at the same locations as PI interception points would be called. Achieving this is easy because CCM is designed to be implemented on top of plain CORBA products. This means that for implementing the basic COPIs, it's natural to use the PI as a foundation. Furthermore, COPIs have method signatures similar to PIs'.
In contrast, the extended COPIs offer similar but different interception points. Whereas basic interception points are called while the ORB is dispatching a call, the extended interception points are called while the CCM container is dispatching a call (see figure 4).
Figure 4 Architectural orientation of basic and extended interceptors.
However, basic and extended COPIs' flow rules differ in an important way. The extended interceptors can, for example, return a result for a method call and prevent further call processing from reaching the component implementation. This lets them modify a component's behavior without changing component implementation.
The COPI interface's definition doesn't prescribe how to implement the COPI interface or register the interfaces in the container. An OMG specification offers an optional way to do that by using an extended container category and a quality-of-service enabler. 10 Vendors can use other approaches to support COPI interfaces in their containers. You can also use the QoS enabler to implement the hooks for integrating security policies.
CCM has defined the container model to provide a high level of abstraction to the component implementation. It also offers the possibility to load and unload user code (components) dynamically by installing or uninstalling homes. Depending on the mechanism that the container vendor and programming language use, this is realized by loading and unloading shared libraries, and it requires sophisticated management of such artifacts at runtime. This feature is implemented in QoS Enabled Distributed Objects ( http://www.qedo.org).
The same principle is applied to the implementation of the COPI interface by defining the QoS enabler. A QoS enabler is a specialized component that can be loaded into a specialized CCM container (extension container) and can hook in additional functionality. This approach lets us use plain CCM mechanisms to develop and deploy QoS enablers. The extension container offers the possibility to register COPIs with the container. Each QoS enabler is responsible for a specific QoS category. We used a QoS enabler to implement access control. Here, it implements the policy enforcement point. During initialization, it loads and instantiates the security policy. At runtime, it intercepts the invocations, calls the policy evaluator, and, if the invocation isn't permitted, raises an exception.
The only condition that must be ensured at runtime is that a corresponding QoS enabler be instantiated on each relevant node. Furthermore, each QoS enabler will be in contact with the policy framework to get an update on the security policies that must be enforced and to centrally log security events such as policy violations.
At runtime, the client-side QoS enabler checks the calling component's identity at the interception point send_request. It adds a security context to the call context. The server-side QoS enabler is called at the interception point receive_request. The QoS enabler checks the origin identity and the target identity and checks whether a policy exists that must be applied for that call.
QoS enablers are components and can be loaded, removed, and configured like normal application components. This, of course, raises security issues. For example, if the QoS enabler is unprotected, an attacker could simply disable the policy enforcement by removing the OpenPMF QoS enabler. In our implementation, this isn't possible because OpenPMF protects the complete underlying infrastructure.
We're evaluating our concepts in the AD4 project ( http://www.objectsecurity.com/en-projects-ad4.html), which aims to develop an innovative 3D visualization system for air traffic control. We implemented the visualization system using CCM and integrated it with the existing ATC simulation systems Eurocontrol Escape and Vitrociset Atres. The functionality of these simulation systems and other data sources (such as weather data) is also wrapped in CORBA components.
From an architectural viewpoint, AD4 is similar to future network-centric ATC and collaborative decision-making systems. It also shares many similarities with military network-centric warfare. It integrates data from different sources and organizations and visualizes them for human decision makers, which raises several security concerns. Such large, highly integrated systems involve many organizations that have different security standards, are from various countries, and therefore face a high risk of attack. So, we developed AD4 as a prototypical secure application. Although we initially planned it as an academic exercise, during the project's course it turned into reality. The simulation platforms run at different project partners' sites and must be used securely over the Internet, reflecting the target applications' real architecture and environment.
As a middleware platform for AD4, we use SecureMiddleware ( http://www.securemiddleware.org), our reference implementation of the concepts we described here. It consists of Qedo, an enhanced implementation of the CORBA Components Model with QoS support, MICO ( http://www.mico.org)(a CORBA ORB with improved support for security), and OpenPMF with underlying security infrastructure such as a public-key infrastructure and directory services. In addition to the CCM runtime platform, SecureMiddleware includes a model-driven development tool chain based on the OMG's Model-Driven Architecture. This tool chain greatly reduces the complexity in designing the system and defining security policies by raising the level of abstraction. Developers can define application components and access control policies in a platform-independent way by using UML2. A model transformation builds platform-specific models (CCM models and security models) that application designers and developers can additionally refine later using a graphical modeling tool. Additional model transformations create programming language-specific artifacts and specific security rules.
Before we could develop AD4's security architecture, we had to analyze the security requirements. Although confidentiality plays the most important role in many secure systems, especially in the military domain, in our system it's a lesser concern. Our most important security objectives are availability and integrity. First of all, internal or external attackers must be prevented from disrupting the system's operation—for example, by crashing it. We also had to ensure that no attacker can spoof tracks or modify other data.
Access control protects the integrity of information. Only authorized sources can feed data into the system, and we also control human users' access to the system by using OpenPMF access control policies. For operative interfaces, we use the role-based access control model. For event-based communication, which implements the main information flow in the system, mandatory access control would be a possible choice. But because our system doesn't process confidential information, we just allow certain flows using access control rules without labels or clearances.
The security policy's correctness is important here. If the policy doesn't explicitly allow an interaction, the policy evaluator automatically denies it. In an ATC system, this can have serious consequences. As we learned while developing the system, manually defining the security policies is difficult and error-prone. Human security administrators can't define the security policy with a sufficient level of assurance because of the high overall complexity of the system and its interactions. So, we integrated the policy definition into the various steps of the model-driven engineering process and used a model transformation to automatically generate the security policies from the application's functional model.
The QoS enablers and OpenPMF provide access control on the components' interfaces and their infrastructure. This means, for example, that an attacker can't successfully inject false tracks into the system or reconfigure it. But this security enforcement at the end points doesn't protect from denial-of-service attacks; an attacker would still be able to overload the system. Full protection against such attacks is impossible. To reduce this risk, we segment the system into different domains. Within a domain—for example, a control center—the risk of a DoS attack is low and could be easily countered because physical access to the local systems is limited. Between the domains—and, in this case, also between the organizations and the Internet—we used a domain boundary controller. Our DBC, the ObjectWall IIOP Proxy ( http://www.objectwall.com), is also integrated with OpenPMF and forwards all legitimate requests that ObjectWall's OpenPMF evaluator has authenticated and authorized according to the security policy at the DBC. An attacker can still launch a DoS attack against the DBC and stop communication between domains but can no longer attack the core functionality inside a domain.
After some smaller tests, we implemented a first version of AD4 with simplified business logic. We installed it at our project partners' sites to evaluate the communication, middleware, and security infrastructures in a real-world setting.
A security system that too greatly impairs overall performance isn't really usable. In the current version of SecureMiddleware, we considered performance optimizations at the architectural level but not really at code level. We also haven't yet run extended benchmarks, which is a difficult task anyway. Some preliminary tests, mainly empty calls with a default crypto suite, showed that encryption, especially authentication, considerably influences the system's overall performance—especially the CPU time, which doubled. The additional effect of the PIs and the policy evaluation is low. The CPU time used increases by several percentage points, while the difference in the wall time is approximately 10 to 15 percent. In our test applications, security enforcement hasn't raised any performance issues, so we haven't yet implemented code optimizations.
Apart from the policy definition issue, policy management and enforcement at the QoS enablers worked as expected and met the initial requirements. ObjectSecurity was able to define and enforce appropriate policies of sufficient granularity to centrally manage the policies and policy evaluators in a large-scale distributed system and to monitor all relevant events.
Many of these concepts are based on previous and related work in middleware security, both in ongoing research and in existing standards and implementations. For example, using PIs to implement access control is common in CORBA security. 3 An overview of middleware security approaches that focus on access control and CORBA is available elsewhere. 4
Separating functional and nonfunctional aspects is crucial when developing reusable components and secure systems, but it's hard to fully achieve with today's platforms. We evaluated our secure middleware in several test applications, and it's successfully being used in an experimental ATC system deployed across the Internet. It meets all initial design requirements. Together with other security infrastructure like the ObjectWall IIOP Proxy, it's an important building block for the development of secure systems.
However, manually defining security policies turned out to be cumbersome. We overcame this by integrating security into the model-based software engineering process, resulting in automated and assisted policy generation. Our system currently mainly targets relatively static applications because it doesn't yet fully meet highly dynamic systems' requirements. In the near future, we plan to add policy-based adaptation.
Cite this article: Tom Ritter, Rudolf Schreiner, and Ulrich Lang, "Integrating Security Policies via Container Portable Interceptors," IEEE Distributed Systems Online, vol. 7, no. 7, 2006, art. no. 0607-o7001.