Authentication protocols

In WebSphere Application Server, there are two authentication protocols to choose from: IBM Secure Association Service (SAS) and Common Secure Interoperability Version 2 (CSIv2). The IBM SAS is the authentication protocol used by all previous releases of WebSphere Application Server and thus is maintained for backwards compatibility. The Object Management Group (OMG) has defined a new authentication protocol, called CSIv2, so that vendors can interoperate securely. CSIv2 has been implemented in WebSphere Application Server Version 5 with more features than SAS and is considered the strategic protocol.

Invoking enterprise bean methods in a secure WebSphere Application Server environment requires an authentication protocol to determine the level of security and type of authentication, which occurs between any given client and server for each request. It is the job of the authentication protocol during a method invocation to coalesce the server authentication requirements (determined by the object IOR) with the client authentication requirements (determined by the client configuration) and come up with an authentication policy specific to that client and server pair.

The authentication policy makes the following decisions, among others, based on both the client and server configurations:

You can configure both protocols (IBM SAS and CSIv2) to work simultaneously. If a server supports both protocols, it exports an IOR containing tagged components describing the configuration for IBM SAS and CSIv2. If a client supports both protocols, it reads tagged components for both IBM SAS and CSIv2. If the client supports both and the server supports both, CSIv2 is used. However, if the server supports IBM SAS (for example, it is a previous WebSphere Application Server release) and the client supports both, the client uses IBM SAS for the request. The protocol is specified by the com.ibm.CSI.protocol property on the client side, is configured through the administrative console on the server side.

Common Secure Interoperability Specification, Version 2

The Common Secure Interoperability Specification, Version 2 (CSIv2) defines the Security Attribute Service (SAS) that enables interoperable authentication, delegation and privileges. The CSIv2 SAS and IBM SAS protocols are entirely different. The CSIv2 SAS protocol is a subcomponent of CSIv2, and supports SSL and interoperability with the EJB Specification Version 2.0. For more information, see CSIv2 features.

Security Attribute Service

The Common Secure Interoperability Specification, Version 2 Security Attribute Service (CSIv2 SAS) protocol is designed to exchange its protocol elements in the service context of GIOP request and reply messages that are communicated over a connection-based transport. The protocol is intended for in environments where transport layer security, such as that available through SSL and TLS, provides message protection (that is, integrity, confidentiality, or both) and server-to-client authentication. The protocol provides client authentication, delegation and privilege functionality that can be applied to overcome corresponding deficiencies in an underlying transport. The CSIv2 SAS protocol facilitates interoperability by serving as the higher-level protocol under which secure transports can be unified.

Connection and request interceptors

The authentication protocols used by WebSphere Application Server are add-on Interoperable Inter-ORB Protocol (IIOP) services. IIOP is a request-and-reply communications protocol used to send messages between two Object Request Brokers (ORBs). For each request made by a client ORB to a server ORB, there is an associated reply made by the server ORB back to the client ORB. Prior to any request flowing, a connection between the client ORB and server ORB must be established over the TCP/IP transport (SSL is a secure version of TCP/IP). The client ORB invokes the authentication protocol client connection interceptor, which is used to read the tagged components in the IOR of the object located on the server. As mentioned previously, this is where the authentication policy is established for the request. Given the authentication policy (a coalescing of the server configuration with the client configuration), the strength of the connection is returned to the ORB. The ORB makes the appropriate connection, usually over SSL.

After the connection is established, the client ORB invokes the authentication protocol client request interceptor, which is used to send security information other than what is established by the transport. This includes the user ID and password token (authenticated by the server), an authentication mechanism-specific token (validated by the server), or an identity assertion token (identity assertion is a way for one server to trust another server without the need to re-authenticate or re-validate the originating client. However, some work is required to trust the upstream server). This additional security information is sent along with the message in a service context. A service context has a registered identifier so that the server ORB can identity which protocol is sending the information. The fact that a service context contains a unique identity is another way for WebSphere Application Server to support both SAS and CSIv2 simultaneously, since both protocols have different service context IDs. Once the client request interceptor finishes adding the service context to the message, the message is sent to the server ORB.

When the message is received by the server ORB, the ORB invokes the authentication protocol server request interceptor. This interceptor looks for the service context ID known by the protocol. When both SAS and CSIv2 are supported by a server, two different server request interceptors are invoked at this point and both interceptors look for different service context IDs. However, only one finds a service context for any given request. When the server request interceptor finds a service context, it 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. A credential contains additional information about the client, retrieved from the user registry so that authorization can make the appropriate decision. Authorization is the process of determining if the user should be able to invoke the request based on the roles applied to the method and the roles given to the user. If the request is rejected by the security server, a reply is sent back to the client without ever invoking the business method.

If no service context is found by the CSIv2 server request interceptor, it then looks at the transport connection to see if a client certificate chain was sent. This is done when SSL client authentication is configured between the client and server. If a client certificate chain is found, the distinguished name (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 LocalOS, 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. When invalid security information is presented, the method request is rejected and a NO_PERMISSION exception is sent back with the reply. However, when no security information is presented, 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 again invoked to complete server authentication and a new reply service context can be created to inform the client request interceptor of the outcome. This process is typically for making the request stateful. When a stateful request is made, only the first request between a client and server requires security information to be sent. All subsequent method requests need only send a unique context ID so that the server may look up the credential stored in a session table. The context ID is unique within the connection between a client and server.

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 or false). Specifying a stateful server is done through the administrative console configuration.

Flow for CSIv2

Authentication policy for each request

The authentication policy of a given request determines what is performed in terms of security protection between a client and a server. A client and 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 may 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 get one from a certificate authority (CA). Some clients may not want the trouble of doing these actions, therefore, they can configure this feature as not supported. By making this decision, it cannot communicate with a secure server requiring client certificate authentication. Instead, this client may 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 since 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.