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 don't supply a username and password will be rejected (with the exception of the super-user on localhost, so that Enterprise Manager doesn't get locked out). When a client does authenticate, the UM client-server protocol automatically signals the server whether they're 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.