Summary SSL and HTTPS

From a developers perspective, nothing special is required to write the user−specific code. In our example, the authenticated user will execute this object, which provides the number of files in the files directory. When the listFiles method is called, the access controller will be called with the stack shown earlier in Figure 15−1. If this class has the appropriate file permission associated with the current user, it will execute correctly. If not, it will throw a SecurityException .

15.3 Simple JAAS Administration

To run our simple example, we must take several administrative steps; in fact, JAAS places a much bigger burden on the administrator than on the developer. The system administrator must configure a set of login modules that will be executed by the login context, write a set of JAAS policy files for the application, and ensure that the program environment is set up correctly to run the application.

15.3.1 Configuring Login Modules

The login context object is quite complex, despite its simple interface. It is built to support a set of pluggable, stackable login modules. A login module is the code that actually authenticates a user. Depending on the module, this may entail either interacting with the user asking for a login name and password or using existing information in the users environment to authenticate the user. A login module may succeed or fail in its attempt to authenticate a user. Login modules are called pluggable because they are loaded dynamically. Instead of calling specific login modules in your code, the login context looks up the login configuration file to see which classes to call. This allows you to use login modules supplied by third parties. Login modules are called stackable because you can specify more than one login module in the configuration file. These modules stack within the configuration file; they are called in order, and each one can add one or more principal objects to the current subject i.e., the current user. This is how subject objects end up with multiple principals: they may come from a single login module, or they may come from several login modules. A sample login configuration file looks like this: CountFiles { com.sun.security.auth.module.SolarisLoginModule required; com.sun.security.auth.module.JndiLoginModule optional; }; DBApplication { com.sun.security.auth.module.NTLoginModule required; }; The login configuration file can have any arbitrary name. This example contains two tags. The tag of the CountFiles entry in the first example is matched to the name that is passed to the login context constructor. Once an entry is found, each of the classes listed is called in order. The entry for a particular class has this format: classname control−flag [optional parameters]; The classname is the full classname of the login module you want to use. The control flag is either required , sufficient , requisite , or optional ; well discuss the meanings of these later. The 296 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.