S. Demurjian, K. Bessette, and T. Doan

Middleware Security

S. Demurjian, K. Bessette, and T. Doan

Computer Science & Engineering Dept.

The University of Connecticut

Storrs, CT 06269-3155

Tel: 860.486.4818

C. Phillips

Dept. of EE & CS

United States Military Academy

West Point, NY 10996

Tel: 845-938-5564

Abstract

Middleware security encompasses a wide range of potential considerations, ranging from the ability to utilize the security capabilities of middleware solutions (e.g., CORBA, .NET, J2EE, DCE, etc.) directly “out-of-the-box” in support of a distributed application to leveraging the middleware itself (paradigm) to realize complex and intricate security solutions (e.g., discretionary access control, role-based access control, mandatory access control, etc.). The objective in this chapter is to address both of these dimensions: exploring the security capabilities of three dominant middleware platforms, namely, CORBA, .NET, and J2EE; and, examining the attainment of advanced security capabilities using the middleware paradigm, namely, role-based access control (RBAC) and mandatory access control (MAC). In the process, we compare and contrast from varied perspectives, detailing the breadth and depth of out-of-the box middleware security, and reflecting on the realization of advance security via middleware platforms.

1. Introduction

Distributed computing applications for the 21st century, constructed from legacy, commercial-off-the-shelf (COTS), database, and new client/server applications, require stakeholders (i.e., software architects, system designers, security officers, etc.) to architect and prototype solutions that facilitate the interoperation of new and existing applications in a network centric environment. In these solutions, security must play a fundamental part, considered at early and all stages of the design and development lifecycle. The emergence of distributed computing technology such as DCE [OSF94, Rose92], CORBA [OMG02a, Vino97, Yang96], DCOM/OLE [Micr95], J2EE/EJB [Roma99, Vale99], JINI [Arno99, Wald99], and .NET [Rior02, Scep02] has enabled the parallel and distributed processing of large, computation-intensive applications. Historically, the incorporation of security has often been an afterthought, dependent on programmatic effort rather than a cohesive mechanism seamlessly incorporated into the underlying technology. However, there has been a dramatic turnaround in the support of security, particularly in modern middleware platforms like CORBA, .NET, and J2EE. The objective of this chapter is a two-fold examination of the concepts and capabilities of middleware security: exploring the security capabilities in three popular middleware platforms, namely, CORBA, .NET, and J2EE; and, utilizing middleware concepts to realize complex and critical security approaches, namely, role-based and mandatory access control.

Towards this objective, in Section 2 of this chapter, we discuss the state of the art in support of middleware security focusing on the security abilities of CORBA, .NET, and J2EE. For CORBA, we explore its security features for confidentiality, integrity, accountability, and availability [OMG02b], keeping in mind that CORBA security is a meta-model that characterizes a breadth of security capabilities representing different security models, paradigms, and techniques. On the other hand, .NET and J2EE provide actual security capabilities via their respective runtime environments, and the application programmer interfaces (APIs) which provide security functionality. As such, .NET and J2EE can be considered, at some level, a realization of the CORBA security meta-model, implementing a subset of its features and capabilities. Thus, for both .Net and J2EE, we present and discuss their security potential and features with a five-prong approach: code-based access control for security embedded in actual program code, role-based access control for user-oriented security, secure code verificationandexecution which focuses on runtime security support, secure communication of the exchange of messages and information, and secure code anddata protection to detail cryptographic capabilities. When relevant, we compare and contrast the features of .Net and J2EE, and we also note their similarities to different portions of the CORBA meta-model. Overall, in Section 2, we cover a range of security capabilities from conceptual (meta-model of CORBA) to practical (.NET and J2EE).

In Section 3 of this chapter, we demonstrate the utilization of middleware to realize complex security capabilities for distributed applications, namely, role-based access control (RBAC) and mandatory access control (MAC). We report on an RBAC/MAC security model and enforcement framework for a distributed environment comprised of software resources interacting via middleware [Phil02a, Phil02b, Phil03a, Phil03b]. Our approach concentrates on the services (APIs) of software resources, providing the means to customize and restrict by time intervals, data values, and clearance levels, allowing different users to have limited access to resource APIs based on role and security level. For enforcement of privileges, the Unified Security Resource (USR) provides the security infrastructure via middleware services: Security Policy Services to manage roles and their privileges; Security Authorization Services to authorize roles to users; and, Security Registration Services to identify clients and track security behavior. These services are used by administrative tools to manage roles by granting/revoking privileges and setting classification levels, to assign clearances and authorize roles to end users, and to handle the delegation of responsibilities from user to user. We report on the current prototype of the USR enforcement framework, which utilizes both CORBA and JINI as the underlying middleware [DSEC], to provide insight on utilizing middleware to realize sophisticated and complex security capabilities. Finally, Section 4 offers concluding and summary remarks.

2. Security in CORBA, .NET, and J2EE

In this section, we explore the security capabilities of CORBA [OMG02b], .NET [MSDN03], and J2EE [JAVA03], highlighting their features and providing a context that explains their approaches. The major difference between the support for security in CORBA (as opposed to its realization in an actual CORBA product, e.g., Visibroker) and security in .NET/J2EE is that the CORBA security specification is a meta-model, akin to the fact that UML is a meta-model with various implementations (e.g., Together, Rational, etc.). As a meta-model, the CORBA security specification is attempting to generalize many security models and associated security principles, to arrive at a specification that is comprehensive (wide variety of security capabilities at the model level - RBAC, MAC, encryption, etc.) while simultaneously being language independent (not tied to Java, C++, .NET, etc.). As such, the CORBA security specification is a step above .NET/J2EE, each of which, in fact, can be characterized as an implementation or instance of the CORBA security meta-model. The reality is that the CORBA security specification itself [OMG02b] emphasizes that there is no single security model and associated implementation that satisfies all of the capabilities and features of the CORBA security meta-model. Our objective in this section is to introduce and highlight the security capabilities of CORBA (Section 2.1), .NET (Section 2.2), and J2EE (Section 2.3). When relevant, we accentuate the similarities and differences of the three approaches.

2.1 CORBA Security Capabilities

In this section, we examine the CORBA Security Service Specification [OMG02b] for the CORBA middleware framework [OMG02a]. Unlike its .NET and J2EE counterparts, the CORBA Security Service Specification is a meta-model, containing capabilities that span a broad spectrum of security features and techniques. The CORBA Security Service Specification focuses on four keys aspects of security: confidentiality, integrity, accountability and availability. Confidentiality is concerned with access to information, to limit access to those individuals (programs) that have been given explicit permission. Integrity has a similar meaning to the database concept of integrity (correct and consistent data values), but in the context of security, is focused on the idea that only authorized users are allowed to modify information in specific ways (e.g., read, update, delete, etc.), and that the delegation of this authorization between users is tightly controlled. Accountability involves the fact that users must be responsible for all of their actions, and that security mechanisms must be able to monitor and track the accountability. Lastly, if users have been appropriately authorized, then their authorizations require the system's availability. These four aspects in turn lead to six key features of the CORBA security model: identification and authentication of users (are they who they say they are), where users can be clients, software artifacts, etc., who must provide proof to verify themselves prior to access; authorization and access control of users to objects (does a user have permission to do what s/he wants), with authorization involving the granting, denying, and revocation of access to objects, and access control the means to realize the privilege definition process and to support enforcement; security auditing for both the accountability of a user’s actions and to track those actions in an audit (security log); security of communication between the users and the objects that they interact with, to insure that not just the permissions (access control) are satisfied, but that the exchange of information and messages is secure; non-repudiation to provide proof of access, both on the transmission from the client, and on the receipt by the target object; and, administration of all of the security requirements for an application, which includes the security policy, users, roles, permissions, etc.

The remainder of this section reviews the CORBA security model, details the access control process in CORBA, explores the different security views that are supported, and concludes by briefly examining the execution process of a secure access request. Note that the material in this section is from [OMG02b], adapted and rewritten to be consistent with the discussion on security middleware. Since the CORBA security specification [OMG02b] is extensive (400+ pages), it is impossible in this context to present its breadth and depth. Thus, the objective is to introduce the reader to its core underlying concepts.

2.1.1 The CORBA Security Model

In Figure 1, we present the interactions of a client and target object using CORBA (and ORB) in the presence of active security services and capabilities. The structural model of CORBA is comprised of different levels used to facilitate secure object invocation by clients. First, there are application-level components, such as a client request services and a target object providing services (see Figure 1). The degree that application-level components are aware of security can vary; the visibility of security can be dependent on programmatic actions whether the client (or user) and/or the target object (application) is cognizant of security or not. Second, as shown in Figure 1, there are many different components that realize security, including: the ORB core and its services, the ORB security services, and the policy objects that contain the actual security requirements for an application (not shown). In Figure 1, there are two ORB security services: the Access Control Service, which verifies from the client perspective if the operation being requested is permitted, and if so, enforces the audit actions that track the actual access; and, the Secure Invocation Service which on the client side is used to connect the client to the target object and on the target side is used to protect the target object in its interactions with the client. Third, their actual security services must be implemented at some point by the middleware; in Figure 1, this is referring to the fact that both the Access Control and Secure Invocation Service specifications must be available in actual CORBA platforms (implementations). These implementations, that are platform specific, must interact with the security and other features that are supported by the OS and hardware.

2.1.2 Access Control in CORBA

In this section, we begin to focus on the details of CORBA security (see Figure 1 again) by investigating the privilege definition process as it relates to the client and the target object, and as it involves the interactions of the client and the target object. In the CORBA security reference model, the access control process must verify the characteristics of a subject's permissions (via privilege attributes) against the target objects which are themselves managed via control attributes (grouped as domains) and operations (grouped as rights). The combination of privilege attributes, control attributes, and domains provides the means to define security requirements, and provides the basis for enforcing those requirements by actual clients against target objects, as shown in Figure 1.

Privilege attributes are associated with the user (client or other software artifact), referred to as the principal, and are used to capture all of the various security permissions for access control, including: the identity (e.g., user id) of the principal, the role(s) of the principal, the group(s) that the principal belongs to in the organization, the security clearance (e.g., secret, classified, etc.) of the principal, the target objects and operations to which the principal has been granted access, and any other enterprise-wide privileges. Clearly, privilege attributes contain the security requirements for each user (principal). Control attributes are associated with each target object, to track the security privileges for an object's perspective. While privilege attributes focused on capabilities of individual principals, control attributes track all of the principals (and their access) on a target-object-by-target-object basis. For example, an access control list entry for each target object would track the list of principals who have been authorized. In addition, control attributes can also track security information on the target object itself. For example, a target object might have a security classification (e.g., secret, classified, etc.), or may be limited in access to certain time periods. Finally, note that the rights of a target object are the set of operations that are available for assignment to each principal. For example, this may be the right to invoke a method, modify a portion of the target object, and so on.

Defining privileges for principals and target objects, while not a difficult process, can be time consuming and complex, when one considers, for even a moderate sized organization, the number of principals, and more importantly, the tens or hundreds of thousands (or more) of target objects for which security must be defined. To assist in this process, the idea of a domain can be leveraged, which provides a context to define common characteristics and capabilities related to security. We focus on the security policy domain that represents the scope over which each security policy is enforced, assuming that an organization may have multiple policies. A security policy domain permits the definition of security requirements for a group of target objects, allowing this group to be managed as a whole, thereby reducing the needed administrative effort. To address the structural aspects of an organization in the security definition process, policy domain hierarchies can be employed. A policy domain hierarchy allows a security administrator to design a hierarchy of policy domains, and then delegate subsets of the hierarchy (sub-domain) to different individuals. For example, in a health care organization, they could be sub-domains for patient objects, test-result objects, employee objects, etc., and the security for these sub-domains could be delegated to different people in hospital administration/IT. This separation into sub-domains allows both access control and auditing to also be administered at these levels, doling out the responsibility for these tasks. There are also other abstraction techniques to organize the security definition process, including: federated policy domains, system- and application-enforced policies, and overlapping policy domains [OMG02b].

2.1.3 Security User Views

The CORBA-compliant security model can be viewed differently by five types of user: the enterprise manager, the end user, the application developer, the operation system administrator, and the object system implementer. We briefly review each of these views:

The Enterprise Management View encompasses an organization-wide perspective on the treatment of security requirements. The objective of this view is to protect all of the information assets of the organization (enterprise), and to accomplish this at a reasonable cost. Risk assessment, protection against malicious and inadvertent security breaches, countermeasures, etc., are all part of this view. The end result will be the definition of security policies, as appropriate, for different portions of an organization.
The End User View focuses on the actual, individual principal (see Section 2.1.2), the privileges that are authorized, and the authentication that must take place to permit the user to perform his/her tasks against specific target objects according to a particular job's responsibilities. As such, the end user view involves the privilege attributes (e.g., user id, role, clearance, etc.).
The Application Developer View focuses on the degree that stakeholders (e.g., software engineers, programmers, developers, etc.) must be aware of the security capabilities of the enterprise. In some situations, the enterprise may wish to define security, but make those definitions transparent to the majority of stakeholders. In this case, the ORB security services could be automatically called to enforce security of the principals against target objects. In other situations, the security may be the strict responsibility of all stakeholders, who would interact explicitly and programmatically with the security services.
The Administrator’s View is the security management perspective, providing all of the capabilities to administer and control security policy definition and enforcement, including: creating and maintaining the domains, assigning the privilege attributes to end users, administrating the security policies, monitoring the control attributes of target objects, etc.
The Object System Implementer’s View differs from the application developers’ view, since these stakeholders are actually responsible for prototyping and implementing the ORB, and for our purposes, the ORB security services. Remember, it may be the case that a given enterprise decides to implement its own unique security services; this view is intended for this situation.

Overall, these various views are all critical, since they collectively provide the means and context to detail and realize all of the security requirements for an organization.