+

Search Tips   |   Advanced Search

EJB authentication policy

The Object Management Group (OMG) has defined the authentication protocol called CSIv2 so that vendors can interoperate securely. WebSphere Application Server v9.0 servers support the CSIv2 authentication protocol only. SAS is supported only between v6.0.x and previous version servers that have been federated in a v6.1 cell. SAS is only maintained for backwards compatibility.

The authentication protocol determines the level of security and the type of authentication that occurs between any given client and server for each request. During a method invocation the protocol merges the server authentication requirements (determined by the object Interoperable Object Reference (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:

We can configure both protocols (SAS and CSIv2) to work simultaneously. If a server supports both protocols, it exports an IOR containing tagged components describing the configuration for SAS and CSIv2. If a client supports both protocols, it reads tagged components for both CSIv2 and SAS. If the client supports both and the server supports both, CSIv2 is used. However, if the server supports SAS (for example, it is a previous WAS release) and the client supports both, the client chooses SAS for this request because the SAS protocol is what both have in common.

Choose a protocol by specifying the com.ibm.CSI.protocol property on the client side and configuring through the administrative console on the server side.


Authentication protocol flow


Interoperable Inter-ORB Protocol (IIOP) services

WAS uses Interoperable Inter-ORB Protocol (IIOP) services over TCP/IP transports. IIOP is a request-and-reply communications protocol. For each client Object Request Broker (ORB) request an associated reply is made by the server ORB back to the client ORB. The client ORB invokes the authentication protocol client connection interceptor, which reads the tagged components in the IOR of the object on the server. The authentication policy is then established via a coalescing of the server configuration with the client configuration.

  1. The client ORB establishes a connection and invokes the authentication protocol client request interceptor.

  2. The interceptor creates a service context containing any of the following additional security information:

    • The user ID and password token authenticated by the server
    • An authentication mechanism-specific token validated by the server
    • An identity assertion token allowing upstream servers to trust re-authentication

    SAS and CSIv2 protocols have different service context IDs which allows WAS to support both simultaneously.

  3. The message is sent to the server ORB.

  4. The server ORB invokes the authentication protocol server request interceptor which looks for the service context ID known by the protocol.

  5. The server request interceptor reads the information in the service context and a method is invoked to the security server to authenticate or validate client identity.

  6. 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 can invoke the request based on the roles applied to the method and the roles given to the user.

  7. If a service context is not found by the CSIv2 server request interceptor, the interceptor process looks at the transport connection to see if a client certificate chain is sent.

    This process is done when SSL client authentication is configured between the client and server.

  8. 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 certificate does not map, no credential is created and the request is rejected.

    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, we can configure this feature as not supported. By making this decision, the client cannot communicate with a secure server that requires client certificate authentication. Instead, this client can choose to use the user ID and password as the method of authenticating itself to the server.

  9. 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.

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

    When valid security information is not 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. 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.

  11. 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.

    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 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. The context ID is unique within the connection between a client and server.

  12. 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 that the client-side stateful context ID can be confirmed and reused.

    Specifying a stateful client is done using the console via the property...

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


Subtopics