Configure CSIv2 outbound authentication

Outbound authentication refers to the configuration that determines the type of authentication that is performed for outbound requests to downstream servers. There are several layers or methods of authentication that can occur. The downstream server inbound authentication configuration must support at least one choice made in this server outbound authentication configuration. If nothing is supported, the request might go outbound as unauthenticated. This does not create a security problem because the authorization run time is responsible for preventing access to protected resources. However, if you choose to prevent an unauthenticated credential to go outbound, you might want to designate one of the authentication layers as required, rather than supported. If a downstream server does not support authentication, when authentication is required the method request fails to go outbound.

The following choices are available in the Common Secure Interoperability Version 2 (CSIv2) Outbound Authentication panel. Remember that you are not required to complete these steps in the displayed order. Rather, these steps are provided to help you understand your choices for configuring outbound authentication.

To configure the CSIv2 outbound authentication, perform the following steps in the WebSphere administrative console:

  1. In the navigation menu, click Security --> Authentication Protocol --> CSI Outbound Authentication.

  2. Select the authentication type:

    • Identity Assertion (attribute layer). When selected, this server submits an identity token to a downstream server, if the downstream server supports identity assertion. When an originating client authenticates to this server, the authentication information that is supplied is preserved in the outbound identity token. If the client authenticating to this server uses client certificate authentication, then the identity token format is a certificate chain, containing the exact client certificate chain on the socket. The same scenario is true for other mechanisms of authentication. For more information, see Identity assertion.

    • User ID and Password (message layer). This type of authentication is the most typical. The user ID and password (if BasicAuth credential) or authenticated token (if authenticated credential) are sent outbound to the downstream server if the downstream server supports message layer authentication in the inbound authentication panel. For more information, see Message layer authentication.

    • Client certificate authentication (transport layer). The main reason to enable outbound Secure Sockets Layer (SSL) client authentication from one server to a downstream server is to create a trusted environment between those servers. For delegating client credentials, use one of the two layers mentioned previously. However, you might want to create SSL personal certificates for all servers in your domain, and only trust those servers in your SSL truststore file. No other servers or clients can connect to the servers in your domain, except at the tiers where you want them. This process can protect your enterprise bean servers from access by anything other than your servlet servers. See Secure Socket Layer Client Certificate authentication (Transport Layer Authentication) for more information.

    A server can send multiple layers simultaneously, therefore, an order of precedence rule decides which identity to use. The identity assertion layer has the highest priority, the message layer follows, and the transport layer has the lowest priority. SSL client certificates are only used as the identity for invoking method requests, when that is the only layer provided. SSL client certificates are useful for trust purposes, even if the identity is not used for the request. If only the message layer and transport layer are provided, the message layer is used to establish the identity for authorization. If the identity assertion layer is provided (regardless of what is provided), then the identity from the identity token is always used by the authorization engine as the identity for that request.

    Typically, the outbound authentication configuration is for an upstream server to communicate with a downstream server. Most likely, the upstream server is a servlet server and the downstream server is an EJB server. On a servlet server, the client authentication performed to access the servlet can be one of many different types of authentication, including client certificate and basic authentication. When receiving basic authentication data, whether through a prompt login or a form-based login, the basic authentication information is typically authenticated to form a credential of the mechanism type that is supported by the server, such as Lightweight Third Party Authentication (LTPA) or LocalOS. When LTPA is the mechanism, a forwardable token exists in the credential. Choose the message layer (BasicAuth) authentication to propagate the client credentials. If the credential was created using a certificate login and you want to preserve sending the certificate downstream, you may decide to go outbound with identity assertion.

  3. Session management. You can choose either stateful or stateless security. Performance is optimum when choosing stateful sessions. The first method request between this server and the downstream server is authenticated. All subsequent requests reuse the session information, including the credential. A unique session entry is defined as the combination of a unique client authentication token and an identity token, scoped to the connection.

For more information about the settings, see the administrative console help topic, CSI outbound authentication settings. Go to Help documentation

When you finish configuring this panel, you configured the information that this server uses to make decisions about the type of authentication to perform with downstream servers. If the downstream server is configured not to support the outbound configuration of the server, the following exception likely occurs:

Exception received: org.omg.CORBA.INITIALIZE: 
JSAS1477W: SECURITY CLIENT/SERVER CONFIG MISMATCH:
  The client security configuration (sas.client.props or outbound settings in GUI)
  does not support the server security configuration for the following reasons:
ERROR 1: JSAS0607E: The client requires SSL Confidentiality but the server does not
                    support it. 
ERROR 2: JSAS0610E: The server requires SSL Integrity but the client does not
                    support it. 
ERROR 3: JSAS0612E: The client requires client (e.g., userid/password or token), 
                    but the server does not support it. 
minor code: 0  completed: No 
  at com.ibm.ISecurityLocalObjectBaseL13Impl.SecurityConnectionInterceptor.getConnectionKey
    (SecurityConnectionInterceptor.java:1770) 
  at com.ibm.ws.orbimpl.transport.WSTransport.getConnection(Unknown Source) 
  at com.ibm.rmi.iiop.TransportManager.get(TransportManager.java:79) 
  at com.ibm.rmi.iiop.GIOPImpl.locate(GIOPImpl.java:167) 
  at com.ibm.CORBA.iiop.ClientDelegate._createRequest(ClientDelegate.java:2088) 
  at com.ibm.CORBA.iiop.ClientDelegate.createRequest(ClientDelegate.java:1264) 
  at com.ibm.CORBA.iiop.ClientDelegate.createRequest(ClientDelegate.java:1177) 
  at com.ibm.CORBA.iiop.ClientDelegate.request(ClientDelegate.java:1726) 
  at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:245) 
  at com.ibm.WsnOptimizedNaming._NamingContextStub.get_compatibility_level(Unknown Source) 
  at com.ibm.websphere.naming.DumpNameSpace.getIdlLevel(DumpNameSpace.java:300) 
  at com.ibm.websphere.naming.DumpNameSpace.getStartingContext(DumpNameSpace.java:329) 
  at com.ibm.websphere.naming.DumpNameSpace.main(DumpNameSpace.java:268) 
  at java.lang.reflect.Method.invoke(Native Method) 
  at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:163)

Note: The reasons for the mismatch are explained in the exception. You can make the corrections when you configure the outbound configuration for this server, or when you configure the inbound configuration of the downstream server. If there are multiple reasons for a failure, the reasons are explained as message text in the exception.