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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
This package allows for the generation and checking of evidence so that actions cannot be repudiated after the event.
These packages standardize a way to integrate third-party Security Service implementations with a CORBA product. There are two relevant packages:
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.
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:
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.
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).
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:
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.
The following subsections briefly discuss some issues that are outside the scope of CORBASEC.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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).
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:
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.
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.
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.
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.
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.
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?
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.
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.
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].