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 is a user ID and password token ,that is, Generic Security Services Username Password (GSSUP), or a mechanism-specific format token, LTPA, for example, this is considered message layer authentication because the data is sent along with the message inside a service context.
A pure Java client will use basic authentication (GSSUP) as the authentication mechanism to establish client identity. However, a servlet can use either basic authentication (GSSUP) or the authentication mechanism of the server (LTPA) to send security information in the message layer. Use LTPA by authenticating or mapping the basic authentication credentials 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. The OID and the client token are sent to the server, so that the server knows which mechanism to use when reading and validating the token. A list of the OIDs for each mechanism follows:
BasicAuth (GSSUP):  oid:2.23.130.1.1.1 
LTPA:    oid:1.3.18.0.2.30.2 
SWAM:     No OID since it is not forwardable
On the server, the authentication mechanisms can interpret the token and create a credential, or they can authenticate basic authentication data from the client, and create a credential. Either way, the created credential is the received credential that the authorization check uses to determine if the user has access to invoke the method. One can specify the authentication mechanism by using the com.ibm.CORBA.authenticationTarget property on the client side. (Basic authentication is currently the only valid value.) One can configure the server 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 (that is, get a BasicAuth or token-based credential). To complete this task, specify the com.ibm.CSI.performClientAuthenticationRequired (True or False) and com.ibm.CSI.performClientAuthenticationSupported (True or False) properties. Indicating that client authentication is required implies that it must be done for every request. Indicating that the authentication mechanism is supported implies that it might be done but is not required. For some servers, this option is appropriate if no resources are protected. In most cases it is a best practice to indicate that this is supported. Doing so ensures that client authentication is performed if both the client and server support it, and it is not performed when communicating with certain servers that do not want security, yet the method requests still succeed.

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 back at the client. If you can correct the error by information at the client side, the system automatically performs 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
Failing to find the stateful session on the server

By default, authentication retries are enabled and perform three retries before returning the error to the client. The property used to enable or disable authentication retries is com.ibm.CORBA.authenticationRetryEnabled (True or False). The property used to specify the number of retry attempts is com.ibm.CORBA.authenticationRetryCount .

Immediate validating of a basic authentication login

In WAS V5, a new behavior is defined during request_login for a BasicAuth login . In prior releases, a BasicAuth login takes the user ID and password entered through the loginSource method and creates a BasicAuth credential. If the user ID or password is invalid, the client program does not find out until the first method request is attempted. When the user ID or password is specified during a prompt or programmatic login, the user ID and password are authenticated by default with the security server, with a True or False being returned as the result. If False, an org.omg.SecurityLevel2.LoginFailed exception is returned to the client indicating the user ID and password are invalid. If True, then the BasicAuth credential is returned to the caller of the request_login . To disable this feature on the pure client, specify com.ibm.CORBA.validateBasicAuth=false . By default this feature is set to True. On the server side, specify this property in the security dynamic properties.