Debugging JSSE SSL and HTTPS

public void logout Log the current user out. This invalidates the subject object. This method throws a LoginException if the logout operation fails. public Subject getSubject Return the subject object that represents the authenticated user.

15.2.1.2 The Subject class

The Subject class javax.security.auth.Subject is used to represent an authenticated user. In essence, each user is represented as an array of Principal objects stored by this class. There is an array of objects because each user is likely to have several identifying characteristics. For example, on my Sun system I have a principal that represents me by username sdo, one that represents me by user ID 6058, and many that represent me by the groups to which I belong group 20, group 45. In addition, I may have other identities such as a database login with a name of scott. Since a principal contains only a single name, my identity is modeled as a set of these principals. For the most part, subjects are opaque objects. You can retrieve the entire set of principals from the subject object as well as private and public credentials i.e., keys and certificates if they are set by the login system. Unless youre implementing your own authentication system, you really use the subject object only as an argument to one of the following static methods of the Subject class: public static Object doAsSubject s, PrivilegedAction pa public static Object doAsSubject s, PrivilegedExceptionAction pea public static Object doAsPrivilegedSubject s, PrivilegedAction pa, AccessControlContext acc public static Object doAsPrivilegedSubject s, PrivilegedExceptionAction pa, AccessControlContext acc Execute the run method of the given object on behalf of the given subject possibly with the given access control context. If the run method can throw an exception, you must use a method that requires a PrivilegedExceptionAction parameter; the exception will be wrapped into a PrivilegedExecption . The doAs method looks remarkably similar to the doPrivileged method of the access controller. This is not an accident: the doAs method sets up special checking that the access controller uses to perform permission checking. The details of how that works are coming up next.

15.2.2 The JAAS User−Specific Code

The code that well execute in our simple example looks like this: package javasec.samples.ch15; import java.io.; import java.security.; class CountFilesAction implements PrivilegedAction { public Object run { File f = new FileFile.separatorChar + files; File fArray[] = f.listFiles ; return new IntegerfArray.length; } } 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