Universal Messaging Developer Guide : Enterprise APIs : Enterprise Developer's Guide for Java : Basic Authentication : Client-side Authentication
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).
The client API is controlled by two main Java system properties, namely Nirvana.auth.client.jaaskey and Nirvana.sasl.client.mech.
If set, this means that any authentication should be performed via JAAS, and it specifies the name of the entry to use in the JAAS login configuration, which is typically a text file created by the system administrator. We shall refer to the file here as the JAAS-LCF (Login Configuration File), a version of which must exist on both the client and the server.
The pathname of the JAAS-LCF 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 API for JAAS, and this results in JAAS internally consulting the JAAS-LCF, which 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 administrator, and the JAAS modules configured into a client should obviously be aligned with those configured on the server.
If Nirvana.auth.client.jaaskey is not explicitly set, then the authentication mechanism defaults to SASL.
The special value of Nirvana.auth.client.jaaskey=noauth means that the client will neither perform JAAS authentication nor engage in SASL negotiation, but will instead forward the username and password to the server, which will then authenticate them via its own JAAS configuration.
This specifies which SASL mechanism to use, and the supported options are "Plain" or "CRAM-MD5".
The mechanism defaults to "Plain" if this system property is not set, and the usual SASL trade-offs apply. SASL-Plain transmits the user password in plain text, so it is advisable to only use it over an SSL connection, while Cram-MD5 does not transmit it in plain text, but does require it to be stored in plain text on the server (whereas Plain can work with stored passwords in either plain or encrypted format).
One of the JAAS modules available is the Universal Messaging 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-based modules, and one reason you might opt for this JAAS-SASL hybrid is to chain it with other Software AG JAAS-based modules, in line with your site's JAAS policy.
The API extensions for Java consist of the following new overloaded variants of existing session-creation methods.
public static nSession create(nSessionAttributes attr,
String username, String password)
public static nSession create(nSessionAttributes attr,
nReconnectHandler handler, String username, String password)
public static nSession createMultiplexed(nSession session,
String user, String passwd)
public static nSession createMultiplexed(nSessionAttributes sessionAttributes,
String userName, String passwd)
Constructor -
nRealmNode(nSessionAttributes sAttr, String username, String passwd)
Constructor -
nRealmAdmin(nSessionAttributes sAttr, String username, String password)
Constructor -
nRealmAdmin(nSessionAttributes sAttr, String username, String password,
boolean followMaster)
If you're using the NirvanaContextFactory class (loads the Universal Messaging provider for JMS) as the value of the standard java.naming.factory.initial context-environment key, then the standard context-environment keys java.naming.security.principal and java.naming.security.credentials should be assigned the username and password respectively.
This is standard JNDI configuration, and is compatible with all JNDI-based providers.
Copyright © 2013-2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback