Securing Your Enterprise with CORBA | Java Security Solutions

As you know, CORBA is a product of the Object Management Group (OMG) used to create, delete, store, and access distributed objects and to allow them to interact with each other. CORBA provides a set of services that makes it easy for objects to be transactional, lockable , secure, and persistent. CORBA solutions are very flexible because CORBA provides a protocol independent of language and platform implementation.

Review of CORBA

The Object Request Broker (ORB) is the CORBA object bus that manages the communication between components in the system and even components on other systems. It provides a set of bus- related services such as the following:

Transparency: Your objects are not aware if the services or calls to other components are serviced in the same system or across the network.
Security and transactions: The ORB includes context information in its messages to handle security and transactions.
Static and dynamic method invocations: You can choose to have static or dynamic method bindings.

The ORB interface is an abstract interface for an ORB to abstract applications from implementation details. This interface provides helper functions such as converting object references to strings. Figure 28-1 shows a generic ORB architecture. The client uses the IDL stub and the implementation (typically known as the servant) uses an IDL skeleton. Both the client and the servant share the ORB interface.

Figure 28-1: Generic ORB architecture

When you write a CORBA application, you define a remote interface that describes the interaction between a server and its clients . You use the Interface Definition Language (IDL) to define the object's interfaces to any potential client. This CORBA IDL does not provide implementation details; the methods can be written in any language that provides CORBA bindings such as Java and C++.

The interface between the client and its ORB is implemented in a stub, and the interface between a server object and its ORB is the skeleton . This is similar to the concept of stubs and skeletons in RMI. However, in CORBA, the communication is performed by the ORB and not by the stub components themselves .

The servant is the implementation of the operations defined in the IDL skeleton. The implementation is built using a language that that provides CORBA bindings such as Java or C++.

For remote invocation requests , CORBA provides a common protocol called Internet Inter-ORB Protocol (IIOP). IIOP is the standard General Inter-ORB Protocol (GIOP) with TCP/IP specified as the transport protocol. GIOP is the CORBA standard that defines the messages for inter-ORB communication.

CORBA defines a set of services; you may want to take a look at the OMG site ( www.omg.org ) for more information. Table 28-1 describes some of these services.

Table 28-1: CORBA Services
Service Name	Description
Concurrency Service	Mediates the concurrency control access to an object. If the object is accessed concurrently, its consistency is not compromised.
Licensing Services	Manages the interface to manage software licenses.
Life Cycle Service	Defines operations for the life cycle of objects such as creation, deletion, movement, and copying.
Naming Service	Allows the location of objects that the client intends to use.
Persistence State Service	Provides an interface for persistent storage information.
Query Service	Provides operations for object collections. It is based on the SQL3 specification and Object Query Language (OQL).
Security Service	Provides the overall framework for CORBA security.
Transaction Service	Provides the interfaces for transaction processing essential for distributed applications.

In addition, OMG has defined an IIOP implementation called Secure Inter-ORB Protocol (SECIOP). SECIOP provides secure connections between CORBA clients and servers, but it is very complex and many vendors provide SSL implementations as an alternative. In addition, you can tunnel IIOP through an HTTPS connection.

Overview of CORBA security

The CORBA Security Service specification includes authentication, authorization and access control, secure communication, auditing, and non- repudiation . It does not include a specification for cryptography services; however, it does mention that the ORB implementation must be able to use local security policies. OMG has defined an overall security framework with different levels and structured into several feature packages (again you can find more information in the Security Specification at the www.omg.org site). Table 28-2 briefly describes these packages, based on the Security Services specification.

Authentication and authorization are not specific to CORBA. You can use different methods with CORBA security for authentication and authorization, and you choose which one to use based on your application needs.

Message integrity , assuring that your message is not tampered, and message encryption , for confidentiality, are also supported by CORBA but are not specific to it. CORBA security supports many different types of encryption and addresses all the important ones such as GSS, Kerberos, and SSL. These are explained in Table 28-1.

Non-repudiation , which provides functionality so that neither the sender nor the recipient can deny sending or receiving the message, is provided in an optional package. CORBA security also provides three different levels of privilege delegation. Privilege delegation refers to the ability to delegate the initiating principal identity beyond the invoked object. As discussed in Table 28-2, these levels are identity-based policies without delegation, identity-based policies with unrestricted delegation, and identity- and privilege-based policies with controlled delegation.

Table 28-2: CORBA/ORB Security
Functionality	Description
*Main Security Functionality Package*	An ORB must provide at least one of these levels before it can be a secure ORB.
Level 1	Only the identity of the initiating principal is transmitted from the client and can be delegated to other objects. Be careful, because impersonation is possible.
Level 2	Attributes of the initiating principal are transmitted from the client. These attributes can include audit identities, roles, and groups. These attributes can be delegated to other objects, but restrictions may apply.
*Optional Security Functionality Package*	Functionality that is expected but not generally required to be part of the main security functionality.
Non-repudiation	Provides functionality to generate and check evidence so that actions cannot be repudiated.
Security Replaceability Packages	Specifies if the ORB is structured in a way that allows incorporation of different Security services.
ORB services replaceability package	The ORB uses interceptor interfaces to call object services.
Security Service replaceability package	The ORB may or may not use interceptors but does use replaceability interfaces. Replaceability interfaces allow the Security services to not be required to understand how the ORB works.
Common Secure Interoperability (CSI) Feature Packages	These features provide different levels of secure interoperability. All levels support functionality for mutual authentication between client and target, and message protection - for integrity.
CSI level 0: Identity based policies without delegation	Only the identity of the initiating principal is transmitted from the client to the target. It cannot be delegated to other objects.
CSI level 1: Identity based policies with unrestricted delegation	Only the identity of the initiating principal is transmitted from the client to the target. The identity can be delegated to other objects, and there are no restrictions on its delegation. Be careful, impersonation can happen at this level when an intermediate object can impersonate the user .
CSI level 2: Identity & privilege based policies with controlled delegation	Attributes of the initiating principal are transmitted from the client to the target. These attributes include identities, roles, and groups. The delegation of these attributes to other objects is possible, but subject to restrictions because the initiating principal can control their use.
*SECIOP Interoperability Package*	An ORB with the Secure Inter-ORB Protocol can generate and use security information. The ORB can send and receive secure requests to and from other ORBs using GIOP/IIOP.
*Security Mechanism Packages*	The choice of the mechanism and protocol depends on the application mechanism and facilities requirements.
SPKM Protocol	Supports CSI level 0 using public key technology for keys assigned to both principals and trusted authorities.
GSS Kerberos Protocol	Supports CSI level 1 using secret key technology for keys assigned to both principals and trusted authorities. It may also be used at CSI level 0.
CSI-ECMA Protocol	Supports CSI level 2. It can be used with identity, but not other privileges. Also, if the administrator permits it, it can be used at either CSI level 1 or level 0. It is based on the ECMA GSS-API mechanism.
SSL Protocol	Supports CSI level 0 and does not depend on the SECIOP extensions to IIOP.
SECIOP Plus DCE-CIOP Interoperability	An ORB that supports the SECIOP standard and also provides secure interoperability using the DCE-CIOP protocol.

CORBA principals

A principal is an entity that is registered and authenticated to the system. The most common form of authentication is the username and password combination, for humans , or long- term keys associated with the object, for systems. A principal may be associated with different identities for different purposes, such as initiating a message or resource access. In addition, a principal has privilege attributes and the principal may use some or all the attributes at any given session.

Some examples of these attributes include the principal's access identity, roles granted to the principal, and the groups the principal belongs to. The attributes can be obtained by delegation from other principals, may be available through authentication, or may be public (that is available to anyone ). These attributes are based on access policies.

There are two access policy types. First is the object invocation policy that establishes if the client (based on the current principal) can access the requested operation. The ORB and the security services it uses (for all applications) typically enforce the object invocation policy. The other access policy is the application object access , which is enforced within the client and the target object. The ORB is still required to validate the request parameters and ensure delivery.

The object invocations are restricted by security rules, which are based on security policies. These policies include defining whether the client can access the object and perform the operation. Also based on security policies, a client and target object may establish a secure association.

Security mechanisms use cryptography to establish the secure association and to protect the data between client and target. Security mechanisms, however, differ in the type of cryptography used. For instance, there are three types of key distribution: secret, public, and hybrid. Keys are assigned to clients, targets, and trusted authorities. The secret key distribution is used for the distribution of keys for principals and for message protection.

Public key distribution is used for principal key distribution and may use secret key distribution for message protection. Finally, hybrid key distribution uses secret key technology for principal key distribution within an administration domain, and public key distribution for trusted authorities and between domains. The secure association is affected by underlying security mechanisms such as mutual authentication requirements.

Note	Recall that a domain is a distinct scope that has common characteristics and rules.

Table of content

Java Security Solutions

ISBN: 0764549286
EAN: 2147483647

Year: 2001
Pages: 222

Authors: Rich Helton, Johennie Helton

BUY ON AMAZON

Crystal Reports 9 on Oracle (Database Professionals)

Qshell for iSeries

Beginning Cryptography with Java

Cisco IP Telephony (CIPT) (Authorized Self-Study) (2nd Edition)

Sap Bw: a Step By Step Guide for Bw 2.0

802.11 Wireless Networks: The Definitive Guide, Second Edition