CORBA Security: An Overview

Middleware News Brief (MNB) features news and technical information about Open Source middleware technologies.

May 15, 2002 - By Chris Cleeland, OCI Principal Software Engineer

Introduction

Although CORBA began life without security, in recent years there has been increased focus on adding security features into the palette of tools it offers middleware developers.

Unfortunately, the add-on nature coupled with lack of widespread, credible implementations fostered confusion regarding CORBA Security's use and utility. In this article we scratch the surface and lay the groundwork for demystifying security as it relates to CORBA middleware.

The specification for CORBA Security is part of the CORBAServices family of specifications and is defined in the CORBA Security Specification. The current version is 1.8, document number formal/02-03-11, although TAO implements features based on an earlier draft version of the same spec, security/00-12-02. Unless specifically noted, this article builds on the core concepts put forth in these two documents.

The Philosophy of CORBA Security

Security, as it relates to CORBA middleware, is defined and discussed by the OMG's Security Special Interest Group (SecSIG), chartered by the OMG's Architecture Board (AB). The fact that the AB chartered this SIG is important: it is an indication of how important the OMG at large – and specifically the AB – think security issues are!

Security is so important to CORBA that its specification is tasked and governed by the guardians of the entire CORBA architecture, not delegated to a sub-sub group. In fact, SecSIG not only maintains the CORBA Security specification, it also acts as the primary subject matter expert resource on security issues for any group within the OMG.

With a core-technology mindset, SecSIG defined a security reference model and an implementation architecture, which collectively establish the boundaries of CORBA security by describing how and where a secure system enforces security policies (such as under what conditions entities may access objects), and a structure for implementation by defining the primary actors in any secure system, as well as how secure system implementations can interoperate.

The reference model defines a feature set to satisfy potential security needs of a distributed object system without specifying a feature solution. Some features are purely functional, meant to address the needs of secure applications. Others are architectural, giving object system implementers flexibility when selecting security technology and implementing security services. The TAO 1.2a Developer's Guide (DevGuide) discusses the reference model in depth in Section 29.2.1.

The implementation architecture describes a realization of the model in a way that satisfies the needs of various consumers of the security features of such a system, such as:

  • end users,
  • application developers,
  • system administrators/security managers, and
  • object system implementers.

The architecture defines the responsibilities of the various components that cooperatively realize the features in the reference model and establishes the structural boundaries that separate these components.

While not formally defined this way, we have found it convenient to think of CORBA Security as dealing with the following central elements:

ElementMeaning
Subject A human user or system entity which, may attempt an action within a secure system.
Authentication The act of establishing the identity of a subject. Once authenticated, the subject becomes a Principal.
Principal An authenticated subject. Basically, this is any entity that directly or indirectly causes an invocation to be made against an object.
Credential A container within a secure CORBA system for the security attributes associated with a principal.
Security Association The result of establishment of trust between a specific client and server, possibly enduring several invocations.

Nearly any interaction in CORBA Security can be described (at a high level) using a combination of these five elements. The application developer can (and should) drill down to finer levels of detail within each of these areas, but these five concepts describe CORBA Security at the highest level.

CORBA SECURITY: SOLUTIONS IN N-SPACE

Security solutions available through CORBA Security fit into [at least] a three-dimensional space defined by three orthogonal axes:

  1. Along one axis is Participation, or how actively the application's code gets involved in security.
  2. Another axis is Functionality Level, or which functional features the middleware provides.
  3. Finally, the third axis is Technology, the actual underlying security technology implementation.

These are illustrated in Figure 1.

Figure 1: CORBA Security Space

Figure 1: CORBA Security Space

APPLYING CORBA SECURITY: WHAT AN APPLICATION DOES

Surely, then, applying these concepts to an application must be a complex endeavor, right?

Not necessarily.

When considering the issue of application integration of security, SecSIG defined the scope of an application's participation. In other words, they answered the question, "How much work does a distributed object system developer need to do in order to use CORBA Security?"

The simple answer: nothing. That's right. The minimal level of participation is zero: no changes in application, just "use" of Security-enabled CORBA middleware, such as TAO ("use" means proper configuration, setup, and deployment as defined by the middleware implementation's documentation).

Of course, with this minimal investment, you also get the least return. Moreover, what you get in return is not governed by a specification, so it's incumbent upon the developer to understand the middleware features. You can get more return by investing more.

CORBA Security defines three levels of participation:

  1. Security Unaware. The application relies completely on the middleware for security.
  2. Security Policy Controlling. The application directs the middleware to use specific, predefined policies but relies on the middleware for enforcement.
  3. Security Policy Enforcing. The application directs middleware to use specific policies and actively examines security context information to enforce policy, as well as relying on middleware enforcement.

These are not mutually exclusive; different areas of an application can participate at different levels. Thus, a portion of an application that must regulate its usage carefully may participate at the highest level, security policy enforcing, while another aspect of the application may rely completely on the minimal features offered by the middleware and be security unaware.

THE LAYERS: WHAT CORBA SECURITY MIDDLEWARE PROVIDES

Independent to the application's participation, CORBA divides Security into two layers:

  1. The API, which "implements" the abstractions defined in the Reference Model
  2. The security technology, which constitutes mechanisms like encryption, validation, and the like

This division acts as a hybrid Bridge/Facade, allowing security-aware applications and the ORB to rely on a constant interface to the underlying technology's security features while allowing the actual technology to vary behind the scenes.

The API itself is further subdivided along several lines:

  • Security functionality levels
  • Security replaceability
  • Security interoperability
  • and more

The DevGuide details these in Section 29.2.2. Most users, however, will be primarily concerned with the security functionality levels. These are, for the most part, conveniently encapsulated within IDL modules:

  • Security. Basic interfaces and data types that span all levels
  • SecurityLevel1. The most basic; provides security features to all applications regardless of their level of participation
  • SecurityLevel2. Permits access to credentials and additional policy controls
  • SecurityAdmin. Permits manipulation of administrative features not necessarily related to invocation or other processing

FINDING A PARTICULAR SOLUTION

If you allow that any deployment of CORBA Security with an application is a solution in this space, then where your application falls on each of the three axes in figure 1 is an optimization problem dependent on the needs and requirements of the application itself, its environment, and your choice in middleware.

For example, an application can be completely security unaware and still be deployed with middleware supporting the highest functionality level (SecurityLevel2). Conversely, you can construct a policy-enforcing application using only SecurityLevel1 features, albeit with more difficulty than if you used SecurityLevel2.

WHAT'S IN TAO?

Like many features in TAO, TAO's implementation of CORBA Security is goal-oriented rather than exhaustive, i.e., what needs to be implemented in order to provide the features required as opposed to what needs to be implemented to satisfy all aspects of the specification.

Consistent with that philosophy, TAO provides:

  • Functionality Level 1, with some aspects of Level 2
  • Interoperability at level 0 (CSI 0, see DevGuide section 29.2.2.4)
  • Technology limited to SSLIOP
  • Extensions to gain direct access to SSL protocol information

Of course, minimal participation in the CORBA Security layers doesn't relegate security to a second-class architectural issue. In order for a "security unaware" application to take advantage of the security features within TAO that are "free" (i.e., those that do not require application code changes), there are a number of issues that must be considered. These include the generation and maintenance of certificates, defining security policies, the use of SSLIOP, as well as deployment issues depending on the application environment.

SUMMARY

Using these features, one can build a TAO-based system with reasonable security with little or no disturbance to application code. The developer will have to get deeply familiar with some aspects of OpenSSL, certificates, and details on certificate authorities. These topics are well covered by the DevGuide in Section 29.4 for RSA-based certificates.

In forthcoming security-related Middleware News Briefs, we'll go into more detail on the particular security features implemented within TAO, including:

  • Demonstrating how to dig into underlying OpenSSL structures from within TAO
  • Providing tips for debugging secured applications (irrespective of their level of participation) using standard SSL-related tools
  • Describing how to do everything in Section 29.4 of the DevGuide with DSA (Digital Signature Algorithm)

Acknowledgments

This article was co-written by Principal Software Engineer, Chris Cleeland, and Senior Software Engineer, Rob Martin.

REFERENCES