optional parameters are specified as name=value
entries. We did not list any in our example, but if you wanted to include a parameter to enable debugging, youd do it like this:
com.sun.security.auth.module.NTLoginModule required debug=true;
This prints out certain debugging information on a module−specific basis. All Sun−supplied login modules accept the
debug flag; other modules accept other parameters as mentioned in their individual
documentation.
15.3.1.1 Login control flags
When you stack modules, you can control how they are called via the login control flag. There are four values for this flag:
required This module is always called, and the user must always pass its authentication test.
sufficient If the user passes the authentication test of this module, no other modules except for required ones
will be executed; the user is sufficiently authenticated. requisite
If the user passes the authentication test of this module, other modules will be executed but except for required ones can be failed.
optional The user is allowed to fail this module. However, if all modules are optional, the user must pass at
least one of them. The idea of stackable modules is crucial to understanding how these flags work because their behavior is
altered depending on the order in which they are invoked. Table 15−1 shows how this relationship works. The table assumes that the user has already been successfully authenticated by a module with the flag listed at the
top of the column. Then, if a module with the flag listed in the left column of the table is called, the user may fail or must pass the authentication as indicated.
Table 15−1. Behavior of Login Control Flags
Required Sufficient
Requisite Optional
Required User must pass
User must pass User must pass
User must pass
Sufficient User may fail
Not called User may fail
User may fail
Requisite User must pass
Not called User must pass
User may fail
Optional User may fail
Not called User may fail
User may fail This interaction between flags is complicated and is probably best avoided. In fact, because of the way policy
files work, it is impossible to take full advantage of mixing the stacked flags. The policy flag lists the class that authenticated the user or the principal of the user e.g., his username. If you specify one module as
sufficient and then a second module as requisite, the entries in the policy file that correspond to the login module listed as requisite will never be granted: the user will never have been logged into that module.
15.3.1.2 Sample login modules
JAAS does not come with any login modules; however, there are three modules available as two separate downloads from Suns web site. One download contains the Solaris login module and the JNDI login module;
the other contains the NT login module and the JNDI login module:
The Solaris login module The class name of the Solaris login module is
com.sun.security.auth.module.SolarisLoginModule thats the name you list in the
login configuration file. This module returns three types of principals:
com.sun.security.auth.SolarisPrincipal Contains the login ID UID of the user e.g., sdo.
com.sun.security.auth.SolarisNumericGroupPrincipal Contains the group ID GID for each group to which the user belongs e.g., 20. If the user
belongs to multiple groups, each group is listed in a separate principal. com.sun.security.auth.SolarisNumericUserPrincipal
Contains the user ID e.g., 6058. This module requires no interaction with the user; all information is obtained from the users
environment.
The NT login module The class name of the NT login module is
com.sun.security.auth.module.NTLoginModule .
This module returns six types of principals: com.sun.security.auth.NTDomainPrincipal
Contains a domain name if the user logged into a Windows NT domain, a workgroup name if the user logged into a workgroup, or a machine name if the user logged into a standalone
configuration. com.sun.security.auth.NTUserPrincipal
Contains the users NT login name. com.sun.security.auth.NTSidDomainPrincipal
Contains the string representation of the Windows NT security identifier SID of the domain the user is logged into. If the user is logged into a workgroup or standalone configuration, this
principal is not available. com.sun.security.auth.NTSidGroupPrincipal
Contains the string representation of the Windows NT SID associated with the group to which the user belongs. If the user belongs to more than one group, each group is listed as a different
principal. com.sun.security.auth.NTSidPrimaryGroupPrincipal
Contains the string representation of the users primary group SID. com.sun.security.auth.NTSidUserPrincipal
Contains the string representation of the users SID. This module requires no interaction with the user; all information is obtained from the users
environment. 298
The JNDI login module The JNDI login module allows you to authenticate a user through JNDI JNDI 1.2 is required. Its
class name is com.sun.security.auth.module.JndiLoginModule
. This module requires optional parameters in order to know where the JNDI databases are held; those
parameters take this form:
user.provider.url=name_service_url group.provider.url=name_service_url
The name service URL varies depending on the protocol. For LDAP, you must know the name of the LDAP server and the name of the entry that stores the user or group information. For example, if the
server piccolo holds user entries in its schema, its URL might be ldap:piccoloou=People,o=Sun,c=US depending, of course, on the schema. The schema must be
in the format specified by RFC 2307, which means that the user ID will be retrieved where
uid=username . The password is expected to be in the
userPassword field.
NIS URLs are specified as nis:serverdomainuser for users and nis:serverdomainsystemgroup for groups substitute your NIS server and domain name appropriately.
Note that regardless of the protocol, the URLs must be contained in quotes and the last option must be followed by a semicolon:
MyJndiApp { com.sun.security.auth.module.JndiLoginModule required
user.provider.url=nis:piccolonytech.East.Sun.COMuser group.provider.url=
nis:piccolonytech.East.Sun.COMsystemgroup; }
The JNDI login module uses callbacks to obtain the user ID and password using a technique well look at later. The module can be configured to save each ID and password in its shared state so that
subsequent attempts to authenticate the user can use the saved data rather than requesting it from the user again. You can control how that state is used by setting any of the following optional arguments
to true:
useFirstPass When set, retrieve the username and password from the modules shared state. The retrieved
values are used for authentication. If authentication fails, no retry is attempted. tryFirstPass
When set, retrieve the username and password from the modules shared state. The retrieved values are used for authentication. If authentication fails, ask the user for a new ID and
password and authenticate based on those values. storePass
When set, store the user ID and password in the shared state only if authentication of the user succeeds and the user ID does not already exist in the shared state.
clearPass When set, clear the ID and password in the shared state after authentication is complete.
The principal types returned by this module are identical to those returned by the Solaris login module e.g., a
SolarisPrincipal , a
SolarisNumeric−UserPrincipal , and one or more
SolarisNumericGroupPrincipals .
Other login modules are certainly possible such as a Java smart−card module, though none exist at the time of this writing. Check out Suns Java pages for links to third−party modules.
