CORBA began life without security. However, in recent years there has been increased focus on adding security features into the palette of tools CORBA 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.
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 implication 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, but also acts as the primary subject-matter-expert resource on security issues for any group within the OMG.
With a core-technology mind-set, 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:
While not formally defined this way, we have found it convenient to think of CORBA Security as dealing with the following central elements:
|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.
Security solutions available through CORBA Security fit into [at least] a three-dimensional space defined by three orthogonal axes. Along on axis is Participation, or how actively the application's code gets involved in security. Another axis is Functionality Level, or which functional features the middleware provides. Finally, the third axis is Technology, the actual underlying security technology implementation. These are illustrated in Figure 1.
Figure 1: CORBA Security Space
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 participation of an application. 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:
Independent to the application's participation, CORBA divides Security into two layers: the API, which "implements" the abstractions defined in the Reference Model, and 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, etc. 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 which 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
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 (
Conversely, you can construct a policy-enforcing application using
SecurityLevel1 features, albeit with more
difficulty than if you used
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:
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. 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.
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 OCI CORBA News Briefs, we'll go into more detail on the particular security features implemented within TAO including showing 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, and describe how to do everything in Section 29.4 of the DevGuide with DSA (Digital Signature Algorithm).
Object Computing, Inc (OCI) has been providing educational services to clients, industries and universities since 1993. We offer one of the most comprehensive distributed Object Oriented training curricula in the country. These curricula focus on the fundamentals of OO technology; with close to 40 workshops in OOAD, Java, XML, C++/CORBA and Unix/Linux.
For further information regarding OCI's Educational Services programs, please visit our Educational Services section on the web or contact us at training.
The OCI CORBA News Brief is intended to promote CORBA and object technology in the development of distributed computing applications. Each issue of the CORBA News Brief will feature news and technical information about OCI's supported open-source ORBs (TAO and JacORB), case studies, and examples using CORBA, as well as information about OCI's educational offerings.
The OCI CORBA News Brief is published on a monthly basis. Send ideas for articles of interest to corba.To subscribe or unsubscribe from the CNB mailing list, send mail to majordomo with the line "subscribe cnb" or "unsubscribe cnb" in the body of the message.