Policy file [10] grant statements can optionally includes one or more Principal field.
Inclusion of a Principal field indicates that the user or other entity represented by the specified Principal, executing the specified code, has the designated permissions. Thus, the basic format of a grant statement is as follows:
grant <signer(s) field>, <codeBase URL>
<Principal field(s)> {
permission perm_class_name "target_name", "action";
....
permission perm_class_name "target_name", "action";
};
Where each of the signer, codeBase and Principal field(s) are optional and the order between the fields doesn't matter. A Principal field looks like the following: Principal Principal_class "principal_name". That is, it is the word "Principal" (where case doesn't matter) followed by the (fully qualified) name of a Principal class which implements the
“java.security.Principal” interface and a principal name. All Principal objects have an associated name that can be obtained by calling their getName method. The format used for the name is depending on each Principal implementation. The type of Principal placed in the Subject created by the Kerberos authentication mechanism used by this thesis is
“javax.security.auth.kerberos.KerberosPrincipal”, so that is what should be used as the Principal_class part of our grant statement's Principal designation. User names for
KerberosPrincipals are of the form "name@realm". Thus, if the user name is "mjones" and the realm is "KRBNT-OPS.ABC.COM", the full principal_name designation to use in the grant statement is "mjones@KRBNT-OPS.ABC.COM".
The absence of the signer(s) field signifies “any signer”. That is, whether the code is signed and by whom does not matter. Its value, when specified, is a comma-separated list of one or more aliases that are mapped, using the keystore, to certificates. When the signedBy value is a comma-separated string containing names of multiple signers, for example “Ada, John, Tom”, the relationship is “AND”, not “OR”. A codeBase value
indicates the code source location (URL); you grant the permission(s) to code from that location. The absence of a codeBase entry signifies “any code”; that is, where the code originates from does not matter. A permission entry [9] must begin with the keyword permission and terminate with a semicolon. The perm_class_name specified after the word permission in the previous grammar would be a specific permission type, such as
“java.io.FilePermission” or “java.lang.RuntimePermissio”. The “target_name” is required for all permission types. The “action” is optional for some permission types and required for others. For instance, the “java.io.FilePermission” requires the target to specify the file and the action that specifies the permitted type of file access (“read” or “write” or both).
The following is the security policy for Kerberos server:
/* Grant the local JARS all permissions */
grant codeBase "file:lib${/}*" {
permission java.security.AllPermission;
};
/* Grant permissions to client principal */
grant principal
javax.security.auth.kerberos.KerberosPrincipal "${clientPrincipal}"
{ /* Call sayHello method */
prmission com.sun.securejinime.hello.ServerPermission "sayHello";
};
/* Grant permissions to all principals */
grant {
/* Call getProxyVerifier method */
permission com.sun.securejinime.hello.ServerPermission "getProxyVerifier";
It is possible to include more than one Principal field in a grant statement. If multiple Principal fields are specified, then the permissions in that grant statement are granted only if the Subject associated with the current access control context contains all of those Principals. To grant the same set of permissions to different Principals, create multiple grant statements where each lists the permissions and contains a single Principal field designating one of the Principals.
It is also possible to specify an additional or a different policy file when invoking execution of an application. This can be done via the "-Djava.security.policy" command line
argument, which sets the value of the java.security.policy property. For example, if you use
“java -Djava.security.manager -Djava.security.policy=someURL SomeApp” where someURL is a URL specifying the location of a policy file, then the specified policy file will be loaded in addition to all the policy files that are specified in the security properties file.
4.6 Running the Program
In attempt to execute Secure JiniME program, you should prepare for running
environment first of all: install J2ME CDC Foundation and RMI as described in Appendix A, then place jaas.jar into directory <java.home>/jre/lib, Jini packages that you want to use as described in Appendix C into your project directory. These packages you can download from “java.sun.com/products/jaas/index-10.html” and “www.jini.org”, Kerberos V5 authentication systems installation in “MIT's Kerberos homepage”. Lastly, to execute the application with the Login utility, do the following:
1. Writing all java files, config files, log files and policy files, then replace
"your_user_name@your_realm" in policy file with your user name and realm.
2. Compile all *.java file
3. Create each java file’s .jar file for codebase
4. Place the *.java and *.class files into a directory; *.config, *.login, and *.policy into subdirectory “config”; *.sh or *.bat into subdirectory “scripts”; *.jar into
subdirectory “lib”; *.password, *.keystore, *.cert into subdirectory “prebuiltkeys”.
We recommend it, but you can put all together in a directory and modify all setting depending on your situation.
5. Execute the class, specifying by an appropriate arguments:
i. by -Djava.security.manager that a security manager should be installed, ii. by -Djava.security.policy=<your policy> that the policy file to be used
is .policy.
iii. by -Djava.security.properties=path-to-file/security.properties defines a system property using when running your application
iv. by -Djava.rmi.server.RMIClassLoaderSpi=<your classloaderspi>, https or httpmd server.
v. by -Djava.security.auth.login.config=<your config> that the login configuration file to be used is .conf.
vi. by -Djava.security.krb5.realm=<your_realm> that your Kerberos realm is the one specified.
vii. by -Djava.security.krb5.kdc=<your_kdc> that your Kerberos KDC is the one specified.
viii. by -Djava.protocol.handler.pkgs=net.jini.url, to includes a protocol handler for HTTPMD URLs.
ix. by -Dexport.codebase=<your codebase directory>, a space-separated list of the HTTPMD URLs for use as codebase.
x. by -Dexport.codebase.source= httpmd://$host:8080/<codebase name
>.jar;<crpto>=0, the name of the directory containing the source files corresponding to the URLs in the codebase. <crypto>=md5,sha and so on.
The following is the example to execute server:
java -Djava.security.manager=
-Djava.security.policy=config/krb-server.policy
-Djava.security.auth.login.config=config/krb-server.login
-Djava.protocol.handler.pkgs=net.jini.url
-Djava.security.properties=config/dynamic-policy.security-properties -Djava.rmi.server.RMIClassLoaderSpi=
com.sun.securejinine.hello.MdClassAnnotationProvider -Dexport.codebase.source=lib
-Dexport.codebase=httpmd://$host:8080/server-dl.jar\;md5=0 \ -DclientPrincipal="$CLIENT"@"$REALM"
-DserverPrincipal="$SERVER"@"$REALM"
-DreggiePrincipal="$REGGIE"@"$REALM"
-Djava.security.krb5.realm=$REALM -Djava.security.krb5.kdc=$KDC_HOST -jar lib/server.jar
config/server.config
In addition to pass the name of your application as an argument to login, you would add any arguments required by your application. Type the full command on one line.
Multiple lines are used here for legibility. If the command is too long for your system, you
may need to place it in a .bat file (for Windows) or a .sh file (for UNIX) and then run that file to execute the command.