Server JAAS Authentication with Software AG Security infrastructure component

Universal Messaging can use the Software AG Security Infrastructure component (SIN) to provide server JAAS authentication capabilities. The SIN component provides a variety of options for using different authentication back-ends and implementing flexible authentication scenarios.

Full details of the Software AG Security Infrastructure component are available in the Software AG documentation web site in the document Software AG Infrastructure Administrator's Guide . See the description of the predefined login modules in that guide for details of setting up authentication using JAAS login modules and a description of the parameters available for configuring the login modules.

The SIN modules are delivered with the Universal Messaging distribution and are available on the Universal Messaging server classpath. By default the server is configured to use a JAAS context named UM-Default which is defined in a file jaas.conf, that resides under the server bin directory. The server configuration file Server_Common.conf (again under the server bin directory) defines the path to the JAAS configuration file as the value of the system property java.security.auth.login.config. The name of the JAAS context to be used for authentication is configured through the system property Nirvana.auth.server.jaaskey. Note that when this property is present, the server will use JAAS authentication, overriding any configured legacy directory-based authenticators. Finally, in order to enable the server authentication one needs to switch the flag Nirvana.auth.enabled to Y as well as modify the flag Nirvana.auth.mandatory to Y in order to make authentication mandatory.

The default values that come with a Universal Messaging server instance are:

The UM-Default JAAS context is pre-configured to use the Software AG default internal user repository as an authentication back-end.

Universal Messaging installation delivers a JAAS configuration file that comes with a pre-configured UM-Default JAAS context and templates for a few other authentication scenarios.

Besides using the Software AG internal user repository, SIN offers a variety of options for LDAP authentication:

The LDAP look up method involves logging on to the LDAP server either anonymously (if allowed) or by using a predefined principal, and performing a lookup for a user entry matching a certain attribute. Finally the SIN-specific LDAP login module will attempt to bind with the retrieved user's distinguished name and the supplied password. The following template configuration is provided where you should fill in the required properties:

/*
* Authentication with an LDAP server by looking up users based on an attribute.
* The login module will use the configured principal (parameter "prin") to bind
* and perform a lookup.
* The principal can be omitted if the LDAP server is configured to allow
* anonymous bind and lookup.
* Afterwards the login module will search for an entry under
* the specified root DN with the attribute
* configured through the "uidprop" matching the supplied username.
* The "uidprop" parameter can be omitted, its default value is "cn".
*/
UM-LDAP-Lookup {
com.softwareag.security.sin.is.ldap.lm.LDAPLoginModule sufficient
url="<LDAP URL>"
prin="<principal complete DN>"
cred="<principal password>"
userrootdn="<root DN for searching users>"
uidprop="<user ID property name>";
};

2. Active Directory direct bind

With active directory the SIN-specific LDAP login module offers the possibility for a direct bind with the supplied username and password, using the following configuration template where the user should fill in the active directory URL.

/*
* Authentication with an Active Directory server by binding directly with
* the supplied credentials.
* Active Directory allows for a direct bind with a principal in the
* format "domainPrefix\user".
*/
UM-AD-DirectBind {
com.softwareag.security.sin.is.ldap.lm.LDAPLoginModule sufficient
url="<LDAP URL>"
noPrinIsAnonymous=false
useFQDNForAuth=true;
};

It is also possible to attempt a direct bind against an LDAP server where the bind DN will be constructed by the SIN-specific JAAS login module using a prefix and a suffix, with the supplied username in-between. In this case the user is required to configure the URL of the LDAP server, as well as the prefix and the suffix to be used for the construction of the bind DN:

/*
* Authentication with an LDAP server by building a complete DN and binding directly.
* The bind DN will be composed by prepending the supplied username with the
* value of the "dnprefix" parameter and appending the value
* of the "dnsuffix" parameter.
*/
UM-LDAP-DirectBind-Affixes {
com.softwareag.security.sin.is.ldap.lm.LDAPLoginModule sufficient
url="<LDAP URL>"
noPrinIsAnonymous=false
useaf=true
dnprefix="<Bind DN prefix>"
dnsuffix="<Bind DN suffix>";
};

4. Combination of any of the above

JAAS is extremely flexible and allows for using a combination of different back-ends, such as, several LDAP servers and/or repositories. For example it is possible to configure LDAP authentication with an internal user repository as a fallback mechanism:

/*
* Authentication with an LDAP server through a user lookup, with an
* internal user repository as a fallback mechanism.
* This configuration would first try to log in against the LDAP if that fails
* would try authentication against the internal user repository.
* Similarly one could use several LDAP servers or
* combine more authentication backends.
*/
UM-Combined {
com.softwareag.security.sin.is.ldap.lm.LDAPLoginModule sufficient
url="<LDAP URL>"
prin="<principal complete DN>"
cred="<principal password>"
userrootdn="<root DN for searching users>"
uidprop="<user ID property name>";

com.softwareag.security.jaas.login.internal.InternalLoginModule sufficient
template_section=INTERNAL
internalRepository="../../../../common/conf/users.txt";
};

To use any custom JAAS context, or any of the predefined templates, you would need to modify the value of the Nirvana.auth.server.jaaskey system property inside the Server_Common.conf file in the server bin directory, pointing it to the context to be used. At the moment the context name is globally defined for the entire server.

Note: Since the jaas.conf file is edited manually and requires certain knowledge of the default JAAS configuration file format, there is always the possibility of a syntactic error. Such errors during parsing of the file will be printed to the UMRealmService.log file which resides under the server bin directory.