The language callback JAAS Callbacks

} return pc; } public void refresh { deferredPolicy.refresh ; } } This class is constructed with an instance of the policy class; it takes permissions from that class and adds the new file permissions to it. When it is asked for permissions for a particular subject, it gets the standard permissions for that subject, then iterates through the principal names in that subject and adds a file permission for each of them. So the user with the principal name sdo will be allowed to read, write, and delete all files in the entire hierarchy of filessdo. Depending on the login modules in place, this will grant additional probably harmless permissions. When authenticated with the Solaris login module, this will also grant me permissions on files45, files6058, and files20 based on the other principal types in the subject, which contain my login and group ID numbers. If you need to avoid this, base the permission on particular principal types. To use this, you must instantiate it with an instance of the existing Policy class: javax.security.auth.Policy.setPolicy new UserPolicyjavax.security.auth.Policy.getPolicy ; This is typically done within the main method of the application, but the policy can be changed at any time.

15.4.4 Administering a JAAS Policy

If you write a new JAAS policy class, you can install it either programmatically as we just showed or administratively, by placing the following line into the JREHOMElibsecurityjava.security file: auth.policy.provider=MyPolicyClass This works only for policy classes that have a default constructor; it wont work for our UserPolicy class because that class depends on another Policy class, to which it defers most of its work. However, unlike the core Policy class, this class need not be on the system classpath to be specified in the java.security file. The standard JAAS policy class will read a policy file specified on the command line as − Djava.security.auth.policy=policyfile as shown earlier. You can also set up the java.security file to specify default JAAS policy files by adding this line: auth.policy.url.1=policyURL Substitute the correct URL for policyURL . As with standard policy files, you may specify any number of files in the java.security file; each must be numbered consecutively, starting with 1. If the command−line java.security.auth.policy file is specified with a double equals sign = =, the entries in the java.security file will be ignored. On the other hand, if the property policy.allowSystemProperty in the java.security file is set to false , the command−line property will be ignored. This is all completely analogous to the core Java policy handling, except that there are no JAAS policy files listed by default in the java.security file.

15.4.5 ClientServer Authentication

JAAS is designed to allow you to perform authentication in a client and pass the subject to a server. For that reason, the Subject class and all the principal classes used by JAAS are serializable. And your own Principal classes should also be serializable. Using JAAS in a client−server environment poses no special challenges, though it does require some forethought. One scheme is to perform authentication on the client: in the client code, create the LoginContext and invoke the login method on it. Then call the getSubject method on the context object and send the subject as a serialized object to the server. The server can then use the subject as a parameter to the doAs method. The challenge with this method is that you must set up the login configuration file and JAAS environment on the client. If you write your own login module, you must distribute it as well. And you must be careful about environmental issues: if the Subject class is loaded on the server from the Java extensions directory which is what we usually recommend, your own principal classes must also be loaded from that directory by the server, or object deserialization will fail. This is a property of how object serialization handles class loading; if youre not serializing the Subject object, its not a requirement. The alternate method is to provide authentication on the server. In that case, you must determine how to obtain callback information from the user. If all you need are the user ID and password, the client can simply send that information to the server, which can store it in the necessary callback objects. If you have to handle other callbacks, you must devise your own scheme in order to pass the information between the client and server. Fortunately, you can usually rely only on a user ID and password.

15.4.6 Groups and Roles

JAAS places a large burden on the administrator of a system. One technique that can lessen this burden is to rely on groups or roles. If your system has 1,000 users, you dont want to have 1,000 different entries in the policy file; if you can assemble those users into a few groups, setting up the policy file is much easier. If your application runs on a platform that already supports groups, this is trivial. On Solaris, you can use the SolarisNumericGroupPrincipal class to authenticate users based on the Solaris group to which they belong; you can perform a similar technique using the NTSidGroupPrincipal class on NT systems. If youre writing your own login module, the classes you write to implement the Principal interface can also implement the PrincipalComparator interface com.sun.security.auth.PrincipalComparator . This allows those classes to implement their own group or role checking. The PrincipalComparator interface contains a single method: public boolean impliesSubject s Determine if the given subject is implied by this principal. Say that you write a principal class called DBPrincipal for database administrators. You could implement the implies method such that if the name is DBA, it implies every other DBPrincipal : package javasec.samples.ch15; import java.io.; import java.util.; import java.security.;