Common Secure Interoperability version 2 (CSIv2)

The Common Secure Interoperability version 2 (CSIv2) is an architecture to satisfy the CORBA security interoperability requirements for authentication, delegation, and privileges. The SAS protocol is used in the CSIv2 architecture to exchange tokens in the service contexts of GIOP request and reply messages for the establishment of security contexts. Transport layer security (SSL/TLS) is required by SAS, and it provides two more layers for client authentication and delegation.

The SAS protocol is divided into two layers. The authentication layer is used to perform client authentication where sufficient authentication might not be accomplished in the transport. The attribute layer might be used by a client to push or deliver security attributes, like an identity to a target server where they might be applied in access control decisions. The transport is referred to as another layer in the CSIv2 documentation for ease of discussion, although it is not part of the SAS protocol message and the SAS message sits on the transport.

The previous diagram shows the relationship between the transport layer and the SAS protocol. The transport layer underlies the SAS protocol and contains message protection, target-to-client authentication, and client authentication. The SAS protocol comprises two layers: client authentication, also known as the message layer, and the security attribute layer. The message layer contains client authentication and the security attribute layer contains identity assertion, privileges and authorization attributes, and proxy endorsement.

CSIv2 identity assertion

The CSIv2 identity assertion support in the attribute layer is used to assert an identity from a client process to a server process when the request is performed by using RMI/IIOP.

An assertion is a declaration of one entity to another to accept an identity on its behalf. A client can assert an identity that represents the subject that was effective at the time it started the remote resource. In addition to the identity token that is representing the user, the client process also sends its own identity in either the authentication layer or the transport layer. The target server ensures that the client process is able to assert an identity by performing a trust validation. If the target server trusts the client, then the server uses the asserted identity to create a server-side subject that represents the user that was effective at the client process at the time of invocation.

The client can assert a user who is using a Principal Name identity token. The format of the principal name depends on the user registry that is configured at the client process. The anonymous identity token type is also supported and the server uses the unauthenticated subject when it receives such token.

For information on configuring the CSIV2 attribute layer with identity assertion, see Configuring inbound CSIv2 attribute layer.

CSIv2 authentication layer

The CSIv2 authentication layer is used to carry authentication information from a client process to a server process when the request is performed by using RMI/IIOP.

The CSIv2 authentication layer can contain a token that is sent by the client that the server can then use to authenticate the client. Various token types are supported in the authentication layer. For example, the GSSUP token is used to transmit the client's user name and password, which is validated against the user registry of the target server. The Lightweight Third Party Authentication (LTPA) token is a token that represents the client's user without having to transmit a password, but the user must be authenticated at the client process before the remote method invocation and both the client and server processes must share LTPA keys.

With either token type, the token is used to authenticate the remote user at the server process and create a Subject representation of the Subject that was effective at the client side before the client started the remote object. When identity assertion is also enabled, the authentication layer can contain the security information that represents the client identity while the identity assertion token represents the actual remote user at invocation time.

For information on configuring the CSIV2 authentication layer, see Configuring inbound CSIv2 authentication layer.

CSIv2 transport layer

The Common Secure Interoperability version 2 (CSIv2) transport layer support is used to protect the SAS protocol request message and support client certificate authentication from a client process to a server process.

The main function of the transport layer is to provide the security characteristics of the transmission of the SAS protocol messages from a client to a server process. The messages can be protected by using encryption, signing, or both. The Liberty SSL support is used as the underlying mechanism that is providing such characteristics.

A second function of the transport layer is to provide a source of authentication material when the authentication layer is not used. If identity assertion is enabled and the authentication layer is not enabled, then the client process identity is obtained from the transport's client certificate chain. The target server process authenticates the client's certificate chain by mapping it to a user in its user registry. The certificate chain issuer distinguished name is used to determine if the client is trusted to assert an identity.

If no identity assertion and authentication layer are enabled, the subject that is obtained from mapping the client certificate chain is used as the caller subject when the actual remote method call is started at the target server process. This also applies when the target server's authentication layer is supported, but not required, and the client did not send an authentication token and an identity token.

For information on configuring the CSIV2 attribute layer with identity assertion, see Configuring inbound CSIv2 transport layer.

Key terms

ORB – Object Request Broker.
It mediates object method invocations among entities, which might or might not be collocated in the same process.
Security context
Information that is used to prescribe what the security characteristics are for a particular operation on an object in an ORB. For example, the identity that is to be used during the invocation of the object operation.
Client security service or CSS
The entity that is initiating a SAS protocol request to establish a security context in the Target Security Service for an operation on an object in the target's ORB.
Target security service or TSS
The entity that is receiving a SAS protocol request for the establishment of a security context in relationship to an operation on an object in its ORB. It accepts or denies a request to establish or use a security context.
Client authentication
A token-based mechanism that is used to authenticate the client. GSSUP (Username Password GSS) is the minimum requirement, but there might be others, like LTPA.
Identity assertion
Mechanism by which an intermediary entity vouches for another entity and the TSS uses the asserted identity for the invocation principal. The TSS can decide whether it trusts the proxy that is asserting the identity or not.
Stateless
The security context is only used during the duration of a single request and it is not reused for subsequent requests.
Stateful
The security context can be reused by multiple requests after it is established and until it is invalidated by the TSS or the CSS.
Transport layer security
The security support that is provided by the underlying transport.