CSIv2

 

Overview

WAS v5 has two authentication protocols: SAS and CSIv2.

SAS is maintained for backwards compatibility. CSIv2 is implemented in WAS with more features than SAS and is considered the strategic protocol.

SAS and CSIv2 are used during EJB method invocations to merge server and client authentication requirements, and come up with an authentication policy to answer questions such as:

SAS and CSIv2 can work simultaneously. If the client supports both and the server supports both, CSIv2 is used.

To specify usage of SAS or CSIv2 on the client side, set the com.ibm.CSI.protocol property. On the server side, specify via the console.

 

Features

The following CSIv2 features are available in IBM WAS:

  1. SSL client certificate authentication.

    An additional way to authenticate a client to a server using SSL client authentication.

  2. Message layer authentication.

    Authenticates credential information and sends that information across the network so that a receiving server can interpret it.

  3. Identity assertion.

    Supports a downstream server in accepting the client identity established on an upstream server, without having to reauthenticate. The downstream server trusts the upstream server.

 

Connection and request interceptors

The authentication protocols used by WAS are add-on IIOP services. IIOP is request-and-reply communications protocol used to send messages between two ORBS.

TCP/IP transport connections between ORBs are established when a client ORB invokes a connection interceptor, which reads the tagged components in the IOR of the server ORB and returns the authentication policy, at which point the client ORB establishes a connection.

After the TCP/IP transport connection is established, the client ORB invokes a request interceptor, which sends security information other than that established by the transport, including:

Identity assertion is a way for one server to trust another server without the need to reauthenticate or revalidate the originating client. To work, additional security information is sent with the message in a service context, which identifes which protocol is sending the information. SAS and CSIv2 have different service context IDs.

After the client request interceptor finishes adding the service context to the message, the message is sent to the server ORB.

The server ORB invokes the server request interceptor which reads the information in the service context. A method is invoked to the security server to authenticate or validate client identity.

The security server either rejects the information or returns a credential, which contains additional information about the client, retrieved from the user registry.

If no service context is found, the interceptor then looks at the transport connection to see if a client certificate chain was sent. If found, the DN is extracted from the certificate and is used to map to an identity in the user registry.

If the user registry is LDAP, the search filters defined in the LDAP registry configuration determine how the certificate maps to an entry in the registry.

If the user registry is local OS, the first attribute of the DN maps to the user ID of the registry. This attribute is typically the common name.

If the certificate does not map, no credential is created and the request is rejected.

If the problem is invalid security information, a NO_PERMISSION exception is sent back with the reply.

If the problem is no security information, an unauthenticated credential is created for the request and the authorization engine determines if the method gets invoked or not. For an unauthenticated credential to invoke an EJB method, either no security roles are defined for the method or a special Everyone role is defined for the method.

When the method invocation is completed in the EJB container, the server request interceptor is invoked again to complete server authentication and a new reply service context is created to inform the client request interceptor of the outcome.

When a stateful request is made, only the first request between a client and server requires that security information is sent. All subsequent method requests need to send a unique context ID only so that the server can look up the credential stored in a session table.

Finally, the method request cycle is completed by the client request interceptor receiving a reply from the server with a reply service context providing information so the client side stateful context ID can be confirmed and reused. Specifying a stateful client is done through the property...

com.ibm.CSI.performStateful (true/false)

Specifying a stateful server is done configuration.

The authentication policy of a given request determines the security protection between a client and a server. A client or server authentication protocol configuration can describe required features, supported features and non-supported features. When a client requires a feature, it can only talk to servers that either require or support that feature. When a server requires a feature, it can only talk to clients that either require or support that feature. When a client supports a feature, it can talk to a server that supports or requires that feature, but can also talk to servers that do not support the feature. When a server supports a feature, it can talk to a client that supports or requires the feature, but can also talk to clients that do not support the feature (or chose not to support the feature).

For example, for a client to support client certificate authentication, some setup is required to either generate a self-signed certificate or to get one from a certificate authority (CA). Some clients might not need to complete these actions, therefore, you can configure this feature as not supported. By making this decision, the client cannot communicate with a secure server requiring client certificate authentication. Instead, this client can choose to use the user ID and password as the method of authenticating itself to the server.

Typically, supporting a feature is the most common way of configuring features. It is also the most successful during run time because it is more forgiving than requiring a feature. Knowing how secure servers are configured in your domain, you can choose the right combination for the client to ensure successful method invocations and still get the most security. If you know that all of your servers support both client certificate and user ID and password authentication for the client, you might want to require one and not support the other. If both the user ID and password and the client certificate are supported on the client and server, both are performed but user ID and password take precedence at the server. This action is based on the CSIv2 specification requirements.

 

See Also

Identity assertion
Message layer authentication
SSL client certificate authentication