Configure CSIv2 outbound authentication

 

Outbound authentication refers to the configuration that determines the type of authentication performed for outbound requests to downstream servers. Several layers or methods of authentication 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.

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, then when authentication is required, the method request fails to go outbound.

The following choices are available in the CSIv2 Outbound Authentication panel.

1. Select Identity Assertion (attribute layer).

   The server submits an identity token to a downstream server. When a client authenticates to the server, the authentication information 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.

2. Select User ID and Password (message layer).

   The user ID and password (if BasicAuth credential) or authenticated token (if authenticated credential) are sent outbound to the downstream server.

3. Select SSL Client certificate authentication (transport layer)

   Creates a trusted environment between servers. For delegating client credentials, use one of the two layers mentioned previously, but create SSL personal certificates for all the servers in the domain, and only trust those servers in the 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.

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. Client certificates are only used as the identity for invoking method requests, when that is the only layer provided. 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.

 

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

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)

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 multiple reasons exist for a failure, the reasons are explained as message text in the exception.

Save the configuration and restart the server for the changes to take effect.

 

See Also

Configuring CSIv2 inbound authentication
Common Secure Interoperability outbound authentication settings
Identity assertion
Message layer authentication
SSL client certificate authentication

 

---