Previous Up Next

Chapter 23  Security



The CORBA Security Service (CORBASEC) is defined in a way that is independent of any particular security technology. Instead, the specification can be applied to numerous security protocols, and the CORBASEC APIs shield application developers from differences across security technologies as much as possible. This abstraction from specific security technologies gives CORBA developers the freedom to change the underlying security technologies used in a given system without needing to redesign the applications that use CORBASEC.

23.1  Features of CORBASEC

This section discusses the most important security features that CORBASEC addresses. Constructing secure CORBA systems involves using code or configuration to specify the desired combinations of these features at an appropriate level of detail for your system. These security features are common to many different security protocols or mechanisms.
Authentication.
This is the requirement that entities (for example, people or programs) prove their identity. In CORBASEC terminology, an entity with the ability to use the resources of a system is called a principal. Authentication is the process of verifying an entity's claimed identity. Note that clients can authenticate servers, and vice versa. Authentication can be either mandatory or optional depending on the security requirements of a given system. Successful authentication results in the principal being granted a set of privilege attributes (such as roles, groups, security clearance levels and so on); these are stored in a credentials object and are later considered during authorization. Some examples of different authentication mechanisms that are commonly used are X.509 certificates, usernames and paswords, and smart cards or hardware tokens. An application has separate credentials for each authentication mechanism with which it wishes to authenticate itself.

Authorization.
This is the process of verifying whether or not a principal is allowed to perform a requested action in a system. An example of a commonly used authorization paradigm is Access Control Lists (ACLs). Although the flexibility of ACLs differ among CORBA Security products, ACLs typically allow access to be constrained at varying levels of granularity, such as per-process, per-object, per-interface or per-operation. Some products may also provide ACL functionality that allows access decisions to be made based on the values of parameters passed to IDL operations. Note that during authorization the set of privilege attributes that was determined for the principal during the authentication process is used to control access to system resources.

Data integrity.
This uses techniques such as message digests (a form of cryptographic checksum) to provide protection against malicious modification of messages.

Confidentiality.
This ensures the privacy of message exchanges so that only the intended recipients can read them.

Detection of replayed messages.
This prevents active attackers from replaying previously stored communications.

Detection of misordering.
This prevents an attacker from rearranging messages in a different order to that in which they were sent.

Auditing/logging.
This involves keeping secure records of “who did what” so that access to system resources can be examined at a later time. Some security systems allow registration with a real-time management service that can perform appropriate system-defined alerts.

Delegation.
This is when one user or principal authorizes another to use their identity or privileges, potentially with usage restrictions. Delegation involves controlling and recording the principal identities that are involved in executing a CORBA request across a chain of participating servers. Delegation can be transparent to the authorization process and be based on the current effective principal. Alternatively, some security products additionally allow authorization decisions to be based on delegation constraints associated with a request.

CORBASEC details a very rich model for delegation that includes support for a number of delegation modes of increasing complexity. This is discussed further in Section 23.2.2.

Non-repudiation.
The verb repudiate means to deny, disown or reject as untrue. Non-repudiation means the ability to prove whether or not a principal invoked a particular operation, so that the principal cannot later deny invoking an operation that he or she did, in fact, invoke. This is an advanced feature and, in practice, depends on the existence of an appropriate supporting infrastructure to be able to persistently store and subsequently recover the relevant evidence for disputed actions. Non-repudiation support is an optional conformance point of the CORBASEC specification and is not supported by most current CORBASEC implementations.

23.2  CORBASEC Conformance Levels

The capabilities of CORBASEC are divided into a number of distinct conformance packages that are described in the following subsections.

CORBASEC Level 1 and Level 2 are two packages that define the most important core functionality, over which the other functional packages listed are layered to provide additional security features appropriate to specific deployment environments.

23.2.1  CORBASEC Level 1

CORBASEC Level 1 specifies how secure associations are established between client and server applications to provide authentication, confidentiality, replay and misordering detection, ORB-mediated authorization decision support and auditing. Importantly, CORBASEC Level 1 defines support for security-unaware applications, which involves being able to configure applications to communicate securely, without the need to write security-specific code. This is a very useful feature that removes a whole category of potential security coding errors for simple applications. CORBASEC Level 1 security also supports simple delegation. This allows the identification and subsequent authorization of an originating client when a request is sent from that client to a server and this server then acts on behalf of the originating client when making related requests to other servers. ORB-enforced access control checks must also be supported at this level, the specification gives implementors freedom as to how access decisions are performed.

While a large number of applications can be usefully configured to be secure using only CORBASEC Level 1 functionality, more complex applications may require the use of the CORBASEC Level 2 features outlined below.

23.2.2  CORBASEC Level 2

CORBASEC Level 2 is a superset of CORBASEC Level 1 functionality, all functionality specified for CORBASEC Level 1 applications is also available to CORBASEC Level 2 applications.

23.2.2.1  Security Aware APIs

CORBASEC Level 2 specifies comprehensive API support for security-aware applications. These APIs make it possible for both server and client applications to have finer control over security policies than can be obtained by configuration alone. These APIs allow control over most aspects of CORBASEC security such as how to combine secure and insecure communications, create and use multiple security credentials, and query the details of peer credentials. Normally CORBASEC APIs are used only when the desired functionality is not possible through the use of security-unaware applications. An example of where the use of CORBASEC APIs might be necessary for an application would be when some dynamic computation needs to be executed to determine whether a request should be allowed or denied.

23.2.2.2  Delegation

CORBASEC Level 2 also supports a variety of delegation modes that are important if you need more control over the chain of principals involved in a CORBA request that involves one or more intermediate CORBA servers:
No delegation.
The client permits the intermediate server object to use its privileges for access control decisions, but does not permit them to be delegated. Because of this, the intermediate server object cannot use the client's privileges when invoking upon other objects.

Simple delegation.
The client permits the intermediate object to assume its privileges, both using them for access control decisions and delegating them to others. The target object receives only the client's privileges, and does not know who the intermediate is.

Composite delegation.
The client permits the intermediate object to use its credentials and delegate them. The client's privileges and the intermediate object's privileges are passed to the target, so that both sets of privileges can be individually checked.

Combined privileges delegation.
The client permits the intermediate object to use its privileges. The intermediate object converts these privileges into credentials and combines them with its own credentials. In this case, the target cannot distinguish which privileges come from which principal.

Traced delegation.
The client permits the intermediate object to use its privileges and delegate them. However, at each intermediate object in the chain, the intermediate's privileges are added, and all the privileges are propagated to provide a trace of the delegates in the chain.
A client application may not see the difference between composite delegation, combined privileges delegation and traced delegation; the client may just see them all as some form of composite delegation. However, the target object can obtain the credentials of intermediates and the original client separately if they have been transmitted separately.

Time periods can be applied to restrict the duration of the delegation. In some implementations, the number of invocations may also be controllable.

23.2.2.3  Access Control

In general CORBASEC implementations may use any one of a large number of authorization models. CORBASEC Level 1 does not prescribe a specific authorization model. In contrast, CORBASEC Level 2 requires support for a specific authorization model that is called DomainAccessPolicy. The actual use of this model (as opposed to its mere availability) is not mandatory; customers can (and commonly do) use alternative authorization models.

It can be argued that a specific authorization model should have been an optional part of the specification. This is because CORBA is an integration technology and, as such, it most usefully needs to integrate with the existing security systems that customers have already deployed. Nonetheless the DomainAccessPolicy authorization model is a powerful one; it enables the specification of the required rights for operations that are validated at runtime against the effective rights associated with the current client's privilege attributes.

The Administration of the mapping of rights to operations is also specified by CORBASEC Level 2. Although these administration interfaces are well designed, many customers need their security solutions to integrate with already-deployed, non-CORBA-specific enterprise security infrastructure. An already-deployed infrastructure will probably have its own administration command-line or GUI tools, and the mandated CORBASEC DomainAccessPolicy administration policy may not be of any relevance for such deployments.

23.2.3  Non-repudiation Package

This package allows for the generation and checking of evidence so that actions cannot be repudiated after the event.

23.2.4  Security Replaceability Packages

These packages standardize a way to integrate third-party Security Service implementations with a CORBA product. There are two relevant packages:
ORB Services Replaceability Package.
The ORB uses portable interceptors (Chapter 14) to call on object services, such as transactions or security. An ORB conforming to this specification does not contain any significant transactions- or security-specific code; instead such code is contained in portable interceptors, to which the ORB delegates.

Security Service Replaceability Package.
Even if the ORB does not implement the ORB Services Replaceability Package, it still makes all calls on security services via specified replaceability interfaces.
A CORBA product that supports one or both of these replaceability packages is said to be security ready. A security-ready CORBA product may or may not be bundled with security functionality. However, it is ready to host CORBASEC functionality, which may be implemented by a third-party vendor.

23.2.5  Secure Interoperability

23.2.5.1  Common Secure Interoperability (CSI) Feature Packages

The Common Secure Interoperability (CSI) specification ensures secure interoperability between different vendors' security products. There are three CSI feature packages, each of which provides a different level of secure interoperability:
Level 0.
Identity-based policies without delegation.
Level 1.
Identity-based policies with unrestricted delegation.
Level 2.
Identity-based policies with controlled delegation.
Different vendors' products are interoperable if they support the same level of common secure interoperability and also share support for the same Common Security Protocol (discussed in Section 23.2.5.2). In general the CSI specification describes how interoperability is achieved by embedding TaggedComponent entries in IORs (Section 10.2.3). The actual information embedded in the IOR is specific to the Common Security Protocol Packages that are being used. Clients that support CSI validate the CSI information contained in an IOR against their specified client side security policies to check: CORBA implementations may simultaneously support more than one specific Common Security Protocol Package—this is useful since it facilitates bridging between different security technology domains.

23.2.5.2  Common Security Protocol Packages

A specific common security protocol package contains all functionality that is required for secure vendor-independent interoperability between different orbs over the specific security mechanism to which the package relates. The list of currently available Common Security Protocol Packages is described below. All of the items listed below except for the respective SSL and DCE-CIOP interoperability definitions depend on the implementation of the Secure Inter-ORB Protocol (SECIOP).
SSL protocol
The popular SSL or TLS family of protocols provide Public Key based mutual authentication capabilities (using X.509v3 certificates) as well as confidentiality, integrity, replay and misordering detection capabilities.1 These protocols inherently support identity-based policies without delegation over a secure channel to provide CSI Level 0 capabilities. Note that CSIv2 level 1 or 2 capabilities can also be layered over the basic SSL/TLS protocols to provide a richer security solution and this is covered in Section 23.2.5.3. The TLS protocol is defined in IETF RFC 2246.

GSS Kerberos Protocol
This protocol supports identity based policies with unrestricted delegation (CSI Level 1) using secret key technology for keys assigned to both principals and trusted authorities. It is also possible to use it without delegation (providing CSI Level 0). The GSS Kerberos protocol is based on the IETF GSS Kerberos V5 definition.

SPKM Protocol
This protocol supports identity-based policies without delegation (CSI Level 0) using public key technology for keys assigned to both principals and trusted authorities. The SPKM protocol is based on IETF RFC 2025, “The Simple Public-Key GSS-API Mechanism”.

CSI-ECMA protocol
This protocol supports identity- & privilege-based policies with controlled delegation (CSI Level 2). It can be used with identity, but no other privileges and without delegation restrictions if the administrator permits this (CSI Level 1) and can be used without delegation (CSI Level 0). The CSI-ECMA protocol is based on a SESAME profile of the ECMA GSS-API Mechanism as defined in ECMA 235. There are three CSI-ECMA variants: CSI-ECMA Public Key, CSI-ECMA Secret Key, and CSI-ECMA Hybrid.

DCE-CIOP
This DCE environment specific protocol achieves secure interoperability between ORBs using the DCE-CIOP transport. Is is dependent on the security services provided by DCE and the DCE Authenticated RPC runtime that utilizes those services. DCE-CIOP is not based on the IIOP protocol and is an example of an Environment Specific Interoperability Protocol (Section 11.1).

23.2.5.3  CSI Version 2 Security Attribute Service (CSIv2 SAS) Protocol

This important protocol is layered over the ORB transport functionality and provides additional client authentication, delegation, and privilege functionality that may be applied on top of any security mechanism used at the transport layer. The SAS protocol is usually layered over secure transports that are interoperable as defined by the CSI specification, but it can also be used in conjunction with insecure transports if required.

The SAS protocol is divided into two layers:
  1. The Authentication Layer is used to perform client authentication where sufficient authentication could not be accomplished in the transport. For example the SSL protocol by itself supports only authentication through the use of X.509 certificates. However in conjunction with CSIv2, fully interoperable username-password client authentication and delegation over SSL is possible between different vendors' products.
  2. The Security Attribute Layer (also referred to as the Common Authorization Layer) may be used by a client to deliver privilege and identity attributes to a server where they may be used for authorization and delegation related purposes.
If you plan on integrating CORBA and J2EE applications then you should note that, since version 1.3, the J2EE Application Server specification mandates the use of the CSIv2 SAS protocol over SSL for secure interoperability between CORBA and J2EE applications.

23.3  Issues Not Covered by CORBASEC

The following subsections briefly discuss some issues that are outside the scope of CORBASEC.

23.3.1  Configuration

CORBASEC defines portable APIs for security, but it does not define any details related to the configuration of a security technology. There are two reasons for this.
  1. All security technologies need configuration of some kind and since CORBASEC is a technology-neutral specification, it is impractical for CORBASEC to define any details related to configuration of security technologies.
  2. CORBASEC implementations are available for a wide range of computers, from embedded devices and PDAs, through PCs and UNIX machines, all the way up to mainframes. However, different computer systems often have entirely different configuration mechanisms, even for the same security protocols. There is too much variety in computer systems for a standardized configuration mechanism to be accepted and used by developers and administrators.
A practical ramification is that the source code of a CORBA application that uses security can be written in a portable way, but the configuration and administration of the application will vary from one CORBASEC product to another. CORBASEC does define administration APIs that can be used to administer some standard CORBASEC security policies. However, for the reasons discussed above, these APIs are not sufficient, by themselves, to provide complete portability of security configuration.

23.3.2  Proprietary Enhancements

Some CORBASEC vendors provide proprietary enhancements in the form of APIs that allow access to security functionality not covered by CORBASEC. Such proprietary APIs are sometimes provided to give programmers access to security technology-specific information. For example, a CORBA product that supports IIOP/TLS might provide proprietary APIs that allow access to the X.509v3 extensions associated with a peer's X.509 certificate chain. CORBASEC does not define how this is achieved; it just defines how an abstract AccessID value should be returned to the application, and this is sufficient for many application types.

23.4  Evaluating CORBASEC Implementations

The CORBA Security Service specification [OMGb, OMGa] covers the security requirements of an enormous amount of different types of applications. Do not jump to the conclusion that only a “fully CORBASEC Level 2 compliant” product will suffice for your requirements—you might be ruling out many products that may be more suitable for your specific system. In many cases, an easily-determined subset of CORBASEC functionality is all that is required. When selecting a CORBASEC product, a good approach is to identify what security functionality you need in your system now, and what you are likely to need in the future. Then check this required functionality against that provided by several vendors and built a small proof-of-concept application to validate your understanding of what is possible.

During your evaluation of CORBASEC implementations, you may want to consider the issues discussed in the following subsections.

23.4.1  Adherence to relevant standards

While not mandated by CORBASEC, it is anticipated that CORBASEC implementations should integrate with existing security technologies that are commonly used in industry. It is desirable for a vendor's security implementation to adhere to relevant commonly deployed industry standards wherever possible. Some reasons for this are as follows:

23.4.2  Support for Security-unaware Applications

Does a vendor provide sufficiently powerful support for security-unaware applications? Such support is very important because it involves no programming. However, different vendors' implementations may vary greatly in the scope of their support for security-unaware applications. When evaluating the security-unaware support for a product, pay particular attention to the type of authorization decisions that your applications need to make, and how security credential initialization details are handled.

23.4.3  Pluggable Security Code

This issue is related to support for security-unaware applications (discussed in the previous subsection), but is sufficiently important to warrant a separate discussion. The security requirements of your application may change over time. It is time-consuming (and therefore expensive) to have to modify an application's source code when its security requirements change. Some CORBA vendors provide a proprietary mechanism by which you can write a plug-in, which is code that can be dynamically loaded into an application. A plug-in is typically packaged as a UNIX shared library (a DLL on Windows) for C++ applications, or as a Java class for Java application. A configuration file is used to specify which plug-ins should be loaded by an application; once loaded, a plug-in acts as an interceptor, though its API might not be that of a portable interceptor (Chapter 14). If a vendor supports plug-ins then you should consider using them, rather than calling CORBASEC Level 2 APIs directly from application code. Use of plug-ins increases the modularity (and hence maintainability) of your applications, simply because it keeps “business logic” code separate from security code. This modularity also increases the portability of your application because if you need to use any proprietary security APIs then their usage can be confined to the plug-in.

23.4.4  Portability

Consider the portability of your applications across different vendor products. Security-unaware applications are the easiest to port since it is just configuration information associated with security policies that needs to change. If security-related code is required by your application, does the vendor's product support standard CORBASEC API interfaces for the functionality that you require? Note that if you require access to security mechanism-specific data then it is likely that you will have to use some vendor-proprietary APIs because CORBASEC does not define this type of functionality.

23.4.5  Interoperability

Consider your current and potential interoperability requirements carefully. While every organization's interoperability requirements may be different, currently the most commonly available secure interoperability implementations are those based on CSI interoperability over the SSL/TLS protocols.

I discussed CSIv2 in Section 23.2.5.3 but there is also a simpler Common Secure Interoperability Version 1 (CSIv1) specification for SSL. CSIv1 defines how extremely basic IIOP/SSL connectivity for SSL-enabled ORBs should be achieved. This specification enables IIOP/SSL implementations from different vendors to interoperate securely at a peer-to-peer level over the secure transport. No “higher level” semantics such as delegation or token-based client authentication are defined.

CSIv2 provides a superset of CSIv1 functionality, but note that an ORB implementation may support both versions simultaneously, which would allow backward compatibility with older versions.

23.4.6  Administration of Authentication & Authorization Information

How easy and scalable is the administration of the security rights for principles and separately of the required rights for specific actions? For example, if a company has hundreds of employees and thousands of customers then it would be impractical to manage the security rights for each person individually. Many different authentication and authorization models are possible but, as an example, an approach that some current security products offer involves defining several conceptual groupings of principals such as employee, administrator, customer, premium customer and so on. Administration is performed at the granularity of assigning group membership to various principals. At runtime, when access to a resource is requested the authorization component of the security system determines the group membership requirements for access to the resource and whether the principal satisfies those requirements.

23.4.7  Scalability and Fault Tolerance

Normally the security service is a critical part of the system and you need to understand if it will introduce a central bottleneck or single point of failure for your applications. For example, if the security service requires deployment of processes for authentication and authorization then you should check if these processes are replicated to provide fail-over or load balancing.

23.4.8  Integration with Enterprise Security Systems

Check if a vendor's security product provides out-of-the-box integration with whatever enterprise security system you want to use. If this functionality is not provided out-of-the-box then you may want to consider checking if the product provides a framework that allows you to implement such an integration yourself. It may also be relevant to check if the vendor's solution can help integrate multiple different enterprise security solutions at the same time (see also the related SSO subsection below).

23.4.9  Single-Sign-On Support (SSO)

Single-sign-on allows principals to use their credentials to obtain additional rights or credentials that can be used for the purposes of authentication and authorization across different security domains. Some of the main characteristics of SSO solutions are described below:
Unified logon.
SSO-enabled clients do not have to logon to each distinct security domain. As well as being a convenience for clients, this also can greatly improve the security of sensitive client information. For example, a basic CSIv2 username/password deployment would result in the client providing its password to every server that it contacts. Of course, the client should be configured to use SSL to perform appropriate authentication of the servers before giving them its password, but an SSO solution will limit the visibility of the client's long-lived password to a single carefully authenticated login server and instead will use a short-lived SSO token to communicate with application servers. In general it is good security practice to always limit the visibility of sensitive information to the minimum number of system components that need it.

Bridging across Security Policy Domains.
SSO capabilities can also be used to provide a bridge across different security policy domains that use the same underlying security mechanisms. For example, you could have a trusted federation of security services that serve different security policy domains; in such a deployment, authentication/issuing decisions would be referred to the security service that issued the SSO token.

Bridging across Security Technology Domains.
SSO capabilities can also be used to bridge across different security technology domains. For example, a client can obtain an SSO token with one particular security mechanism and then use this SSO token in conjunction with a different security mechanism that is required by the server. The client may not be capable of performing direct authentication to the server over the second mechanism but the SSO token can provide the additional credential information required.

23.4.10  Key and Password Management

Consider what facilities the vendor's product provides for safely handling security key/password data for your chosen security mechanisms. The use of non-standard data formats or mechanisms for credential-related information would complicate any potential migration to another CORBASEC vendor's solution.

23.4.11  Client-side Security Policies

Some security solutions focus on server-side security to the exclusion of the client. Investigate what features are provided by vendor products to ensure that clients are communicating with the appropriate servers to serve their requests.

23.4.12  Secure corbaloc

As discussed in Chapter 12, corbaloc URLs provide a human-readable alternative to stringified IORs (Section 3.4.2). Unfortunately, the corbaloc specification does not officially support SSL. A common misconception is that this lack of support is irrelevant since it is possible to use insecure communications in conjunction with corbaloc to obtain a secure object reference. However, this is not the same thing as using secure communications from the start to obtain the secure IOR. Without SSL you are obtaining an object reference from an unauthenticated corbaloc server; in theory what you obtain could be a different object reference than that which would have been returned by an authenticated corbaloc server. In general analyzing the security of your system is simpler if you use secure communications everywhere possible. Some vendors provide a proprietary SSL extension to corbaloc functionality to avoid this problem.

23.4.13  Secured CORBA Services

Check whether CORBA services (for example, Naming, Transactions, Notification, and various daemon services) that are supplied by the vendor are security enabled out-of-the-box, or whether they can be configured to be secure using standard security functionality provided by the product.

23.4.14  Firewall traversal

If using IIOP over the Internet is of relevance to you then you may wish to ask if your vendor provides any support for secure traversal of firewalls. Unfortunately agreement upon an OMG firewall traversal specification for IIOP has proven difficult to obtain. This is a complex area but two potential approaches are briefly mentioned in the following subsections.

23.4.15  Firewall Proxy Servers

Some vendors provide IIOP firewall proxy servers that mediate inbound and outbound IIOP requests before forwarding them on to their intended recipient. If a secure firewall traversal solution is important to you then you need to find out if the IIOP firewall supports a consistent integration with the desired enterprise security policies. For example, does it guarantee that the secure association established between the client and the firewall is compatible with the security policies of the intended target?

23.4.16  Bi-directional IIOP

The availability of a bi-directional IIOP solution can help simplify secure navigation across firewalls. It is important to note that CORBA callback objects normally require a separate connection from the server back to the client. This can complicate the port management aspect for a standard firewall. Additionally it may be desired to only support IIOP connections in one direction and not allow outbound IIOP connections at all. Bi-directional IIOP facilitates this by reusing the connection that already exists from the client to the server. If your vendor supports bi-directional IIOP then you should ask for details of how they ensure compatibility of the server's “client side” security policies with the existing connection when it makes callback invocations to the client.

23.5  Final Comments

It is critical to understand that no security product provides total security by itself. Good security software is a “necessary but not sufficient” condition for a secure system in the real world. A naive deployment of perfectly good security products can result in perfectly insecure systems. It is essential that personnel with an appropriate background in security understand the core security mechanisms that are used for a given system and review the overall security of a planned deployment. Expecting developers that have no background or appropriate training in security to “add on” security near the end of a project's development schedule is a recipe for disaster. A related point to this is that developing a secure system involves a different mindset to developing an system without security. For insecure systems, typically everybody is mostly concerned with ensuring that everything that should work does indeed work. For secure systems you also need to ensure that everything that should not work, indeed does not work. Sometimes developers working on the core system see security as an “obstacle that has to be overcome” as opposed to critical functionality in its own right.

23.6  Further Reading

The CORBA Security specifications [OMGb, OMGa] are sources of definitive (but at times tedious) information. A gentler introduction to CORBA security can be found in CORBA Security [Bla99]. Some good books that explain security issues in a non-CORBA-centric way include Cryptography Decrypted [MBB00], Network Security [KPS02] and Applied Cryptography [Sch95].
1
The Transport Layer Security (TLS) protocol is the successor to Netscape's Secure Socket Layer (SSL) protocol. TLS 1.0 is based on SSL 3.0.
Previous Up Next