The text input callback

We failed, and so did someone else, so just clean up. return false; else if succeeded == true commitSucceeded == true { Our login succeeded, but another required module failed. We must remove our principal and clean up. logout ; } else { Our commit failed, even though login succeeded. The rest of our internal state should already have been cleaned up. succeeded = false; } return true; } public boolean logout throws LoginException { if debug System.err.printlnSimpleLoginModule: Logout; subject.getPrincipals .removeprincipal; principal = null; userName = null; succeeded = commitSucceeded = false; return true; } } Because it always succeeds, this is a good module for testing. However, weve indicated the logic in all methods that is necessary to handle failure modes as well. Remember that since login modules can stack, the subject object may have several principals. This is why we dont add the principal to the subject if its already there. This is also why we took care to write a good equals method for the SimplePrincipal class; the default comparison of principal objects is almost never correct, since it compares object references rather than the information contained in the object. Also remember that even if our module succeeds, other modules may fail and invalidate the entire login process; this is why its necessary to keep all the state as we proceed.

15.4.3 The JAAS Policy Class

The implementation of the JAAS policy file is provided by a subclass of the Policy class javax.security.auth.Policy . This subclass is similar in construction to the java.security.Policy class we examined in Chapter 5, but it is not related to the core Policy class. While they provide essentially the same API, they implement two sets of policies and operate independently: one applies to all code, and one applies only to code run under the doAs method. The default implementation of the JAAS policy class is provided by the PolicyFile class com.sun.security.auth.PolicyFile . This class parses the JAAS policy files and presents the appropriate permissions when asked. If you need a different JAAS policy, however, you can provide a different implementation of the Policy class, as well show in this section. One case in which you might want to provide your own JAAS policy class is to implement user−specific permissions based on the principal name of the user. For instance, a file server might have a files directory that contains a number of subdirectories, one for each user: filessdo, filesjra, filesfred, and so on. It is impossible to create a JAAS policy file that allows the subject sdo to read filessdo, the subject jra to read filesjra, and so on. However, you can do this by implementing a new policy class. The JAAS Policy class has four key methods: 312