Universal Messaging 10.5 | Concepts | Security | Authentication | Using SASL | Server-side Authentication | Client Negotiation
 
Client Negotiation
Authentication is disabled by default on the server for backward compatibility, meaning that even if clients do supply user credentials, they will be accepted without verification. This is controlled by the Nirvana.auth.enabled system property, which must be explicitly set to Y or y to enable authentication. System admins have to set up various other config options when enabling authentication, so they would set Nirvana.auth.enabled as part of that effort. Even when authentication is enabled, authenticating clients can exist side-by-side with non-authenticating ones, meaning it is entirely optional for clients to supply any user credentials, and if they don't they will be handled in the traditional Universal Messaging manner.
The Nirvana.auth.mandatory system property controls this behaviour, and should be explicitly set to Y or y to make authentication mandatory, meaning clients that do not supply a username and password are rejected.
The following users are exempt from mandatory authentication:
*The super-user on localhost to prevent being locked out.
*A set of users in a .txt file specified in the optional JVM property -DNirvana.auth.exempt=<path_to_file>. You list the users in the exempt file one per line in ACL-style notation, for example, username1@10.140.2.95.
The exempt file supports wildcard-character entries using the * (asterisk) symbol, such as user@* and *@host. However, *@* is not supported because it will allow any user to bypass authentication.
Note:
The username * is a valid username, but if you add such a user to the exempt list, the user will be read as a wildcard. In such cases, Software AG recommends against using the * username.
When a client does authenticate, the UM client-server protocol automatically signals the server whether they are using SASL or JAAS and if JAAS, then the Nirvana.auth.server.jaaskey system property must be set on the server, and it specifies the name of the entry to use in the JAAS login configuration file. As in the client case, the pathname of this file is specified by the standard JAAS java.security.auth.login.config property. If the Nirvana.auth.server.jaaskey system property is not set, then all attempts to authenticate via JAAS will be rejected.