Client-side Authentication

If the pre-existing session connection methods with no username/password parameters are used, then the client will continue to use unauthenticated sessions as before (assuming the server is configured to allow that), i.e. by defaulting the user identity to the username under whose identity the client process is running (as reflected in the Java user.name system property for Java clients).

The client API is controlled by three main environment variables/system properties:

Note:
The client-side authentication with JAAS has been deprecated in Universal Messaging v10.7 and will be removed from the product in a future release.

If set, this means that any authentication should be performed via JAAS and its value specifies the name of the entry to use in the JAAS login configuration file. JAAS is an established Java standard which is beyond the scope of the UM documentation.

The login configuration file's pathname is specified by the usual JAAS system property, java.security.auth.login.config.

The Universal Messaging client SDK supplies the username and password to the JDK's built-in JAAS subsystem, and the JAAS login config file specifies one or more pluggable JAAS modules that will perform the authentication. The precise modules to use are a matter of site-specific policies determined by the Universal Messaging administrators, and the JAAS modules configured into a client should obviously be aligned with those configured on the server.

This specifies which SASL mechanism to use, and the supported options are PLAIN, CRAM-MD5 and DIGEST-MD5.

The mechanism defaults to PLAIN if this system property is not set, and the usual SASL trade-offs apply. PLAIN transmits the user password in plain text, so it is advisable to only use it over an SSL connection. On the other hand, CRAM-MD5 and DIGEST-MD5 do not transmit the password in plain text so are more appropriate for general connections.

This specifies whether to prehash the supplied password when using the CRAM-MD5 or DIGEST-MD5 mechanisms. It may be set to true or false. This should be set to true only when the server is using the fSAGInternalUserRepositoryAdapter to store client credentials, otherwise CRAM-MD5 and DIGEST-MD5 authentication will fail. If Nirvana.sasl.client.enablePrehash is not set, then the value defaults to false and prehashing is not enabled.

One of the JAAS modules available is the Nirvana class, com.pcbsys.foundation.security.sasl.fSaslClientLoginModule, which will result in the authentication being performed via SASL after all, despite initially being routed via JAAS. From the server's perspective, the authentication negotiation is conducted entirely in SASL. The fSaslClientLoginModule class is integrated with the Software AG family of JAAS modules, and one reason you might opt for this JAAS-SASL hybrid is to chain it with other SAG modules.

Note:
Basic authentication, supplying a username and password, is only supported for Java and .NET clients.

You can use the Nirvana.sasl.client.localhostResolve property to control whether the reverse hostname resolution for localhost is enabled on the client. Valid values:

false - disables reverse hostname resolution. Set to false if you experience SASL-related client connection exceptions over the Universal Messaging Socket Protocol (nsp).

Important:
If you set this property to false, you must also set the Nirvana.sasl.server.localhostResolve property to false.