Message layer authentication

Message layer authentication defines the credential information and sends that information across the network so that a receiving server can interpret it.

When sending authentication information across the network using a token (whether the token be a user ID and password token, or a mechanism-specific format token such as LTPA) this is considered message layer authentication because the data is sent along with the message inside a service context.

A pure Java client uses BasicAuth (GSSUP) as the authentication mechanism to establish the client's identity. However, a servlet can use either BasicAuth or the authentication mechanism of the server (LTPA) to send security information in the message layer. To use LTPA the BasicAuth credentials need to be authenticated or mapped to the security mechanism of the server.

The security token contained in a token-based credential is authentication-mechanism specific. That is, the way the token is interpreted is only known by the authentication mechanism. Therefore, each authentication mechanism has an object ID (OID) representing it and sent along with the token from the client to the server, so that the server knows which mechanism needs to read the token and validate it.

The following list shows the object IDs for each mechanism:

On the server, the authentication mechanisms can interpret the token and create a credential, or they can authenticate BasicAuth data coming over from the client, and create a credential. Either way, the created credential created is the received credential to be used by the authorization check to determine if the user has access to invoke the method. The authentication mechanism can be specified using the com.ibm.CORBA.authenticationTarget property on the client side (the only valid value currently is BasicAuth). The server is configured through the administrative console.

While this property tells you which authentication mechanism to use, you also need to specify whether you want to perform authentication over the message layer (such as through a BasicAuth or token-based credential). To do this, you can specify the com.ibm.CSI.performClientAuthenticationRequired (true or false) and com.ibm.CSI.performClientAuthenticationSupported (true or false) properties. To say that client authentication is required indicates that it must be done for every request. To say that it is supported indicates it may be done but does not need to be done. In most cases, configuring client authentication as supported is adequate. This way, authentcation is performed if both client and server support it. If a server does not support client authentication, the metho request still succeeds.

Configure Authentication Retries

There are situations where you want a prompt to reappear if you have entered your user ID and password incorrectly or you want a method to retry when a particular error occurs in the client. If the error is one that can be corrected by information at the client side, you can automatically perform a retry without the client seeing the failure if it is configured to do so.

Some of these errors include entering an invalid user ID and password, having an expired credential on the server, and not finding the stateful session on the server. By default, authentication retries are enabled and is attempted three times before the error is returned to the client. The property to enable or disable authentication retries is com.ibm.CORBA.authenticationRetryEnabled (true or false). The property to specify the number of retry attempts is com.ibm.CORBA.authenticationRetryCount.

Immediate Validating of a BasicAuth Login

In WebSphere Application Server Version 5.0, a new behavior is defined during request_login for a BasicAuth login. In prior releases, a BasicAuth login took the user ID and password that were entered through the loginSource method to create a BasicAuth credential. If the user ID or password was invalid, the error was not reported to the client until the first method request was attempted. In V5.0, when the user ID or password is specified during a prompt or programmatic login, by default this isauthenticated with the security server with true or false being returned as the result. If false, an org.omg.SecurityLevel2.LoginFailed exception is returned to the client that indicates that the user ID and password are invalid. If true, then the BasicAuth credential is returned to the caller of request_login. To disable this feature on the pure client, specify com.ibm.CORBA.validateBasicAuth=false. By default this is set to true. On the server side, specify this property in the security dynamic properties.