Applicability of CORBA Security to Healthcare Problem Domain

By Konstantin Beznosov
Object Technology Group, Baptist Health Systems of South Florida

OMG document number: corbamed/97-09-11

Copyright 1997, Baptist Health Systems of South Florida

Last updated January 19, 2004


This paper suggests directions OMG Healthcare Domain Task Force (CORBAmed) could take in proposing OMG standards related to security in the healthcare vertical domain. The ideas are based on the experience gained from Computerized Patient Record (CPR) security analysis and design modeling. The CPR security project ( is work in progress. This document's most recent version can be obtained from the project site.


We want to thank Object Technology Group at Baptist Health Systems of South Florida for their input on this paper as well as all those SecSIG and CORBAmed mail lists participants who discussed questions related to security in the healthcare domain.


CORBA Security specification (CORBASEC) allows an application to exercise security service provided by ORB environment (called "system security" here) to this application, or to exercise its own security (called "application security" here). CORBASEC does not prevent someone from re-implementing security inside of an application and from avoiding the use of system security. If a system designer wants to deliver one more stovepipe system, it does not matter what (system or application) security will be employed. If a system is supposed to be extensible and interoperable, and especially if the system is going to act as a component in enterprise infrastructure, a designer will want to use system security as much as possible and use application security only when the system cannot provide the required level of granularity, or flexibility. In the former case, for the system (or application) to be pluggable into enterprise computing environment, application security should still be exercised via horizontal interfaces and metadata provided by an infrastructure in which the component is going to perform.

In this paper, we discuss our vision of how CORBA-based components provided by different vendors can exercise sophisticated security policies in a consistent and uniform way in healthcare enterprises. We state questions that should be addressed by healthcare domain and security task forces. We believe that this paper can serve as a starting point for CORBAmed's track towards a set of specifications on a uniform way of exercising security in CORBA-complient healthcare computing environments.

The paper structure is as follows: First, we give minimal background on the main functionalities security services are supposed to provide in distributed environment. Second, we show why extensive use of horizontal interfaces and metadata is essential to achieve consistency in exercising security across components from different vendors, as well as to achieve independence from enterprise security policies. Third, we show why CORBA-complient components have to exercise application security in order to satisfy security requirements of today's healthcare business. Fourth, we discuss why CORBA-complient components of healthcare providing enterprises should exercise application security in a uniform way. Fifth, we raise questions that, we believe, CORBAmed wants to address in its security related specifications. Then, we mention issues, OMG security community is planning to address, that are essential for deploying CORBA-complient systems in healthcare. We conclude the paper with summarizing its main results. The very last section contains references and explains some terminology.


Here, a principal is a human or system entity that is registered in and authenticatable to a system [CORBASEC].

Comprehensive information security of distributed systems is supposed to implement the following several main functionalities:

  • Principal authentication
    -- determines who is accessing the service
  • Principal authorization (sometimes called "access control")
    -- determines what services can be accessed by an authenticated principal
  • Information integrity
    -- guarantees that data has not been changed since its last official update.
  • Information confidentiality
    -- ensures that only authenticated users can read confidential data.
  • Parties accountability
    -- ensures that principals are accountable for their security-relevant actions. This functionality is usually achieved via the following two functionalities:
    • Activities audit
      -- Makes users accountable for their security related actions.
    • Non-repudiation
      -- provides irrefutable evidence of actions such as proof of origin of data to the recipient, or proof of receipt of data to the sender to protect against subsequent attempts to falsely deny the receiving or sending of data.
  • Availability
    -- ensures that use of the system cannot be maliciously denied to authorized users.

For a very good and brief introduction into CORBA security framework see "Guidelines for Security and CORBA implementation of the PIDS Access Policy Model" written by Polar Humenn ( and posted to PIDS mail list on September 14, 1997.

Horizontal Interfaces, Metadata and CORBASEC

In the case of security environment, an enterprise architecture defines metadata, which describe security policies, and horizontal interfaces, which provide a means to exercise those policies across an enterprise. When there are heterogeneous systems in one enterprise (does anybody have homogenous systems only?) all those systems want to use the same horizontal interfaces in order to exercise consistent security policies. To achieve it, a company wants to require all its vendors to use those interfaces and metadata. We believe that the healthcare problem domain can be analyzed and a set of horizontal interfaces can be defined for the whole healthcare market. Specification of Patient Identification Service (PIDS), which will occur soon, and other activities of CORBAmed are good proof for such belief. CORBASEC is a very good base for building such horizontal interfaces in the security area of healthcare. Indeed, CORBASEC service can even be used directly when security policies are simple and flat. But it is not the case with the healthcare problem domain where, as the experience of CPR analysis and design shows, policies have to be of finer granularity than interface (note, not object) methods invocation and to involve such criteria as principal location, access time, information confidentiality level, etc..

The Need To Exercise Application Security In Healthcare Business Domain

In the healthcare business domain:

  1. Complexity of enforcing access restrictions is the major concern in the threat model (developed by OMG SecSIG and led by Patrick Mallet).
  2. The same threat model priorities are very different from other domains. One of the very first potential harms or damages is denial of service. It is, as you might know, very critical in emergency situations, which often occur in healthcare. Hence, there is a need for so called "soft access control" when a principal is not guaranteed access and audit and (may be even) non-repudiation "alarms" go off for later investigation. Meanwhile, the user is warned that they are accessing information they are not supposed to. Such "soft access control" notion is missing from the more basic "yes/no" model of CORBASEC.
  3. Relationships between a patient and numerous caregivers and among caregivers themselves in regard to that patient are very complex. Even assuming an ideal scenario where we have standardized domain management and composition, given complexity overwhelms the access control model provided by CORBASEC: security attributes ==> effective rights ==> required privileges. For example: the business of providing healthcare services sometimes requires a physician to access patient data that, from an outsider's point of view, does not have anything to do with that particular episode.

The list above leads to the conclusion that a healthcare application might want to exercise its own security (particularly access control) constraints on top of security services provided by ORB. Ideology of CORBASEC agrees with the fact that some vertical domains will require it:

"In a CORBA system, the 'system' security is enforced by the distributed ORB and the Security services it uses and the underlying operating systems that support it. This is the only policy that applies to object unaware of security. The application security policy is enforced by application objects, which have their own security requirements. For example, they may want to control access to their own functions and data at a finer granularity than the system security policy provides." [CORBASEC, 35]

There has to be finer-grained security control than just interface.method one for the content (this is what CORBASEC provides in its current specification). And, this problem is for any specification issued by CORBAmed.

The Need To Exercise Application Security in Uniform Way

According to our vision, the logic of security policy decision should be separated from an application system because:

  • All security related decisions made by an application depend not only on the application business logic but also on security policies that are enforced in the given organization.
  • A vendor, which developed an application system, does not know apriori security policies enforced across customers' enterprises.
  • Such security policies can be changed when legislation changes or when company's businesses process changes.

This is why we believe that a set of enterprise security policies is the first candidate for metadata in the computing infrastructure of a healthcare provider.

Such security metadata can be encapsulated and accessed via interfaces that are external to the application system. If the interfaces are specified, system vendors do not have to worry about idiosyncrasies of security policies and policy changes at their customer enterprises.

CORBASEC specifies such interfaces to access enterprise security policies in a uniform way wherever security policies are simple and can be enforced on system level. In other words, wherever system security suffices. When it is not sufficient to express complexity of a given vertical domain, application security should also be uniform.

Interfaces for accessing security policy decision logic have to be uniform across all components in CORBA-based infrastructure of healthcare providers. If an application is going to exercise its own security on top of CORBASEC, the way it does should be the same as for any other CORBA-based application/system in the enterprise so that:

  • Vendors can rely on the uniform interface to enterprise security infrastructure.
  • Vendors can exercise the interface in a uniform way no matter what customers their systems are deployed at.
  • The way an application makes security decisions (access control, security of communications, audit and so on) depends on security policies across an enterprise and NOT only on what logic the vendor decided to "put in".
  • Security policies across an enterprise can be consistent for ALL components of it.

Here is one of the possible solutions. There can be, so to say, "decision objects" on the application security level that an application wants to "consult" to enforce a particular type of security. Such objects, again, have to be the same for any other applications and systems in CORBAmed.

Another approach , as Polar Humenn correctlry mentioned in the one of mail threads on OMG's SecSIG and CORBAmed's PIDS mail lists, is interceptor mechanisms.

We believe this is what CORBAmed security specification wants to deal with. Once such an interface is specified, previously adopted specifications, like PIDS, will be amended to reflect it.

Issues To Be Addressed By CORBAmed

We see two types of issues CORBAmed needs to address in regard to security in CORBA-complient systems deployed on the healthcare market. They are:

  • Specifying how CORBA-complient applications exercise (on application level) security policies that are defined by a healthcare organization.
  • Defining a profile of those CORBASEC features that are either not required to implement basic security or hard to specify and/or implement in general purpose ORB environments. Such features are intentionally left optional or underspecified. The profile will state what optional features in CORBASEC are mandatory for healthcare domain.

Interfaces to exercise security at application level by CORBA-complient systems in healthcare industry

The following is a suggested list of issues that security aware CORBA-complient systems have to deal with in order to exercise security in uniform way:

  1. One of the best candidates for application security is design where invocation of the same method on the same object can result in accessing patient-identifiable information with different degree of confidentiality.
    What interface should be used to access enterprise security policy to make access decisions for each invocation?
    How should confidentiality level of the patient-identifiable information be passed to such an interface?
    What other information should be passed to such an interface so that it will be sufficient to make decisions and it would not jeopardize overall system and enterprise computing environment performance, scalability, and manageability?
  2. Among information types an application can use to control access, there are action relevant information (e.g. operation, parameters) and context information (e.g. time).
    What particular action relevant and context information should be passed to make fine grain access control decision in healthcare problem domain?
  3. "A client application aware of security can also specify what security policy options it wants to apply when communicating with this target object by performing operations on the target object's reference" [CORBASEC, 100] (see specification of IDL interface for SecurityLevel2::Object).
    If a higher level of communication security is required by enterprise security policy for only some particular invocations (e.g. depending on the time of day) how does an application find out about it?
  4. "A target object can influence the security policy for incoming invocations by setting security policies using the administrative interfaces. This will affect the security information exported as part of its object reference." [CORBASEC, 101]
    How does a target object find out what security policy, if any, it should enforce for incoming invocations?
  5. A client may use different privileges/QoP or controls when invoking different targets or different invocations on the same target reference (override_default).
    How does a client find out what privileges and QoP it should use for different invocations on the same target reference?
  6. Access polices for an application may be enforced in the following ways:
    1.  "Automatically by the ORB services on object invocation, to determine whether the caller has the right to invoke an operation on an object.
    2. By the application itself, to enforce further controls on who can invoke it to do what.
    3. By the application to control access to its own internal functions and state." [CORBASEC, 111]

How does an application find what access control should be enforced in cases 2 and 3 above?

The list is by no means complete. It presents only few questions that are important to find answers on. We believe, CORBAmed will uncover many more issues in its security related specifications.

Security Profile of CORBASEC Features in Healthcare Industry

Defining security a profile of CORBASEC for healthcare clarifies ambiguity present in CORBA Security service specification. The ambiguity is sometimes necessary and sometimes desirable because the service is oriented towards a very broad range of environments and problem domains where it is expected to be applied.

In the healthcare domain, security requirements are more common across enterprises due to the following facts:

  • Healthcare providers have the same information processing patterns.
  • The recent legislation activities in US and existing laws in European community promise to bring a concrete common denominator to security requirements.

Such commonality allows OMG healthcare domain task force to have a more precise security model of the domain business process. The profile will express this model in terms of a feature list that an ORB environment compliant with CORBASEC has to have, in addition to basic compliance, in order to be sufficient for exercising security in healthcare enterprises. It will be more an "implementation guide" for those ORB vendors who want to play on the healthcare informational market, as well as a "consumer book" for those healthcare professionals who are responsible for CORBA-complient technology deployment.

The following is the list of candidate issues for the profile:

  1. What CORBASEC level (0,1,2) is required?
  2. What CORBA Common Secure Interoperability level (0,1,2) is required?
  3. Conforming implementations are not required to support the "request" and "reply" directions: "Some implementations may allow the security features to be set[/get] for communication in one direction only via the direction parameter, but [CORBASEC, 102]
    Is support for setting security features in one direction required?
  4. Since "The way the received and intermediate's own [CORBASEC, 115]
    How should credentials be combined in CompositeDelegation?
  5. "Ability of an intermediate object to make a copy of the incoming credentials, modifying them and then delegating them is " [CORBASEC, 62]
    Should this ability be required or optional?
  6. "Non-repudiation is an [CORBASEC, 115]
    Should non-repudiation functionality be required?

The list is by no means complete. More thorough inspection of CORBASEC will bring up other candidates for the profile.

Issues To Be Addressed By Security Task Force

In this section, we describe few items from larger list of issues that we found very important to address in OMG standardization process in order for CORBASEC to be used in the computing environment of healthcare organizations. These issues are known to OMG security community. By listing them in this paper, we want to make stress on the fact that these issues are essential for deploying CORBA security in healthcare.

Domain Policy Composition and Management

Domain containment hierarchies are very powerful concept that helps to achieve scalable fine-level domain.intreface.method granularity on system security level. It can not be applied for real world problems yet. Security domain management (i.e. creation/deletion of domains, moving objects from one domain to another) and, the most important, domain policy composition (when we have sub- and/or overlapping domains) are not standardized at all. It means there is no way the enterprise architects can assume that systems based on ORBs from different vendors will enforce the same security policies if those policies are based on domains. Neither can they assume that replacing an ORB vendor will not change systems' behavior in regard to domain-based security policies.

Security Policies Management

The more general issue is standardization of security policies management.


Complexity of the healthcare security problem domain requires exercising a more sophisticated security model than the general one used in CORBA Security service. This leads system developers to application level security on top of security provided by ORB systems. At the same time, commonality of security requirements across healthcare computing environments allows exercising security at the application level in a uniform way. Both healthcare market vendors of computing systems based on CORBA technology and healthcare enterprise security designers and administrators will benefit from having standard interfaces to access enterprise security metadata and exercise security at the application level. We believe that such interfaces can be specified by CORBAmed with the help of OMG security-aware community.

After the CORBAmed security interfaces are specified, ambiguity in requirements for an ORB to be CORBA Security compliant can be eliminated by underwriting a specification profile. The profile will clearly state what optional functionality has to be provided by an ORB in order to use it in healthcare computing environments. It will allow application system vendors as well enterprise designers to select adequate ORB environments.

References and Terms

AC -- Access Control

Authentication -- a process of verifying the claimed identity of a principal. Authentication results in authenticity, meaning that the verifying principal (verifier) can be sure that the verified principal (claimant) is the one he or she claims to be Authentication techniques are based on one or a combination of the following: proof by knowledge, proof by possession, proof by property.[Oppliger 1996]

"Common Secure Interoperability", 1996 OMG Document Number: orbos/96-06-20

CA -- Certificate Authority. A trusted third-party that issues and manages (validates, revokes, publishes) digital certificates.

CAC -- Content Access Control. It is control over access to passive resources like plain pages (without active components) over WWW services. Some times, access to active components can be controlled in the same way as CAC. For example, a Web server administrator can restrict access to Java classes accessible from the server. Such AC considered as CAC even though Java classes can be active resources.

"CORBA Core" volume 1, OMG, version 2.0, July 1996 Available in electronic form from.

"CORBA Services" volume 1, OMG, version 1.0, November 1996 Available in electronic form from. Chapter 15 is Security service specification.

CPR -- Computerized/Computer-based Patient Record.

Domain "(as specified in the ORB Interoperability Architecture) is a distinct scope, within which certain common characteristics are exibited and common rules observed."(p.15-33)

Horizontal interfaces are those interfaces that apply to an entire category of subsystems. Horizontal interfaces are described and discussed in [Mowbray 1997].

KISS -- Keep It Simple, Stupid

LDAP -- Lightweight Directory Protocol. It is a specification for a client-server protocol to retrieve and manage directory information. It was originally intended as a means for clients on PCs to access X.500 directories, but can also be used with any other directory system which follows the X.500 data models. There is a LDAP World™ page at Critical Angle that gives a good list of references regarding LDAP.

Metadata is self-descriptive information that defines the dynamic structure of the system. Metadata is described and discussed in [Mowbray 1997].

[Mowbray 1997] Mowbray, Thomas J., Malveau, Raphael C. "CORBA Design Patterns", 1997 Jon Wiley & Sons, Inc.

[Mowbray 1995] Mowbray, Thomas J, Zahavi Ron "The Essential CORBA: Systems Integration Using Distributed Objects", 1995 Jon Wiley & Sons, Inc.

[Oppliger 1996] Rolf Oppliger, "Authentication Systems for Secure Networks", 1996 Artech House, Inc.

Public Key Cryptosystem is a cryptosystem in which a user has a pair of mathimatically related keys. The pair consists of a public key that can be published without doing any harm to the systems's security, and a private key that is assumed to never leave the posession of its owner.[Oppliger 1996]

PID -- Patient ID

PKCS stands for Public Key Cryptography Standard and is a series of cryptographic standards published by RSA Laboratories. See also public key cryptosystem.

Principal -- a human or system entity that is registered in and authenticatable to a system.

QoP -- Quality of Protection

Stovepipe system is a set of legacy applications that resists adaptation to user and organizational needs. Mowbray and Zahavi describe the following characteristics of stovepipe systems in [Mowbray 1995, p.9]:

  • Monolithic, vertically integrated applications
  • Closed system: custom proprietary solution
  • No discernible software architecture
    • System structure poorly understood by developers and maintainers
  • Lack of provision for reuse and extension
  • Slow development and deployment
  • Expensive maintenance and evolution

Secure Sockets Layer (SSL) -- a security protocol, which provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection. Netscape site has dedicated pages about SSL.

SESAME -- a Secure European System for Applications in a Multi-vendor Environment. SESAME is a European research and development project, part funded by the European Commission under its RACE program. It is also the name of the technology that came out of that project. The SESAME technology offers sophisticated single sign-on with added distributed access control features and cryptographic protection of interchanged data. More information on SESAME can found on its page.

X.500 -- X.500 is an Internet standard for directory service and mailb routing.

X.509 -- ISO/IEC 9594-8, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT/ITU Recommendation X.509, 1993. More details on this standard can be found at Gateway to Information Security site.