Security Service (Java Distributed Computing)

B.3. Security Service

The CORBA Security Service specification is one of the more complicated and detailed of the CORBA services. This is in large part due to the inherent complexity of security, and also to the fact that the Security Services specification includes security models and interfaces for application development, security administration, and the implementation of security services themselves.

In this section we'll only provide a brief overview of the security model and interfaces provided within the CORBA Security Services for application development. Later, we'll contrast the Security Services with the Java Security API.

B.3.1. Service Types

The CORBA Security Services provide interfaces for the following:

Authenticating and generating credentials for principals, including the delegation of credentials to intermediary principals
Performing secure transactions (e.g., method invocations, data transfers, etc.) between objects
Auditing secure transactions for later review
Non-repudiation facilities that generate evidence of transactions, to prevent principals involved in a secure transaction from denying that the action ever took place (e.g., the sender of a message denies ever sending it, or the receiver denies receipt)

All of these services and their interfaces are specified in an implementation-neutral manner. So the authentication service interface does not depend on the use of symmetric or asymmetric keys, and the interface to a principal's credentials is not dependent on the use of a particular certificate protocol like X.509.

B.3.2. Security Model

The model used by the CORBA Security Services specification involves principals that are authenticated using a PrincipalAuthenticator object. Once authenticated, a principal is associated with a Credential object, which contains information about its authenticated identity and the access rights that it has under this identity. These credentials are then used in secure transactions, to verify the access privileges of the parties involved, and to register identities for actions that are audited or carried out in a non-repudiation mode. A CORBA remote object request run under the security services is outlined in Figure B-3. The client requests a remote object through a local reference. The client's Credentials (generated earlier by authenticating the user using the PrincipalAuthenticator interface) are attached to the request by the Security Services present in the ORB, and sent along with the request over the transport mechanism in use. The remote object receives the request through its ORB, along with the client's Credentials. The target object can decide whether to honor the request or not, based on the access rights of the client's identity.

Figure B-3. A secure CORBA request

When a request is received from a remote agent, its right to access the resources requested can be checked through an AccessDecision object, which can be used to compare the remote principal's credentials against access control settings, like an ACL. There typically isn't a default access-control policy that the Security Services will enforce for requests, since checking access rights is usually very application-specific (e.g., "Is the client principal in the `Credit Admin' group?", or "Has this principal tried and failed to access this resource more than x times?"). The target of a request can also explicitly audit the transaction using the AuditChannel interface, or just check to see if auditing is required by the current security policy by calling the audit_needed() method on the AuditDecision interface. If non-repudiation services are available, then evidence of the action can be generated using the NRCredentials interface.

B.3.3. Comparison to the Java Security API

The CORBA Security Services specification defines a more comprehensive security API than the Java Security API, in the following ways:

Direct support for security auditing and (through an optional set of interfaces) nonrepudiation services
Direct support for delegation of requests to intermediary objects

However, the two specifications or APIs are also aimed at different goals. The Java Security API is primarily an interface to low-level security measures and utilities, like key generation and management, direct generation of message digests and digital signatures, etc. The CORBA Security Services are at a much higher level, defining a generic interface between applications and high-order security services, such as principal credentials, audit trails, and intermediaries. The Security Services specification never gets down to the level of defining interfaces based on families of security algorithms, like public key encryption. Even the interfaces provided for service implementors only provide hooks into the ORB request-handling and message-transfer functions. Likewise, the Java Security API never rises above the level of algorithm-independent interfaces to key generation, digital signatures, etc. There's no attempt to build a generic interface to credentials and access decisions, just specific interfaces to access-control lists, for example.

In fact, the two can be seen as complementary in many ways; the Java Security API could be considered a toolkit for building a Java implementation of the services defined at a higher level by the CORBA Security Services specification.