The policy for a Javaprogramming language application environment (specifying whichpermissions are available for code from various sources, andexecuting as various principals) is represented by a Policy object.More specifically, it is represented by aPolicysubclass providing an implementation of the abstract methods in thePolicy class (which is in thejava.security package).

The source location for the policy information utilized by thePolicy object is up to the Policy implementation. The Policyreference implementation obtains its information from static policyconfiguration files.

The rest of this document pertains to the Policy referenceimplementation and the syntax that must be used in policy files itreads. For information about using thePolicy Tool to createa policy file (without needing to know the required syntax), seethe Policy Tool documentation (for Solaris) (for Win32).

Here is an outline for the rest of this document:

Policy Changes in theJava 2 SDK, Standard Edition, v1.4

Default PolicyImplementation

Default Policy FileLocations

Changing the PolicyImplementation

Policy File Syntax

Policy File Examples

Property Expansion in PolicyFiles

General Expansion in PolicyFiles

Related Documentation

Policy Changes in theJava 2 SDK, Standard Edition, v1.4

With the integration of JavaAuthentication and Authorization Service (JAAS) into the J2SDK 1.4,thejava.security.Policy API handles Principal-basedqueries, and the default policy implementation supportsPrincipal-basedgrant entries. Thus, access controlcan now be based not just on what code is running, but also onwho is running it. See other sections of this document forfurther information on principal-basedgrantentries.

---

Note: Starting with this version (v 1.4), policy files usedby the default policy implementation must be encoded in the UTF-8encoding scheme. You can use thenative2ascii tool to assist withthis conversion.

---

The rest of this section is relevant only for programmers whoutilize the Policy API. If you're not such a progammer, you canskip to the next sections,Default PolicyImplementation andDefault Policy FileLocations.

Policy-related API changes made in the J2SDK 1.4 include thefollowing:

• java.security.ProtectionDomain

  A new constructor,ProtectionDomain(CodeSource cs, PermissionCollection perms,ClassLoader loader, Principal[] principals), was added.This new constructor creates a newProtectionDomainqualified by the givenCodeSource,Permissions,ClassLoader, andPrincipals.

• java.security.Policy

  Two new methods were added:

  1. getPermissions(ProtectionDomain domain) evaluatesthe system policy and returns aPermissionCollectionobject specifying the set of permissions allowed given thecharacteristics of theProtectionDomain.
  2. implies(ProtectionDomain domain, Permissionpermission) evaluates the system policy for thepermissions granted to theProtectionDomain and testswhether the permission is granted.

Default PolicyImplementation

In the Policy reference implementation, the policy canbe specified within one or more policy configuration files. Theconfiguration file(s) specify what permissions are allowed for codefrom a specified code source, and executed by a specifiedprincipal. Each configuration file must be encoded in UTF-8.

A policy file can be composed via a simple text editor, or viathe graphicalPolicy Tool utility.

There is by default a single system-wide policy file, and asingle (optional) user policy file.

The Policy reference implementation is initialized the firsttime itsgetPermissions method is called, or wheneveritsrefresh method is called. Initialization involvesparsing the policy configuration file(s) (seePolicy File Syntax), and then populating thePolicy object.

Default Policy FileLocations

As mentioned previously, there is by default a singlesystem-wide policy file, and a single user policy file.

The system policy file is by default located at

java.home/lib/security/java.policy  (Solaris)java.home\lib\security\java.policy  (Win32)

Note:java.home refers to the valueof the system property named "java.home", whichspecifies the directory that houses the runtime environment --either thejre directory in the Java 2 SDK or thetop-level directory of the Java 2 Runtime Environment.

The system policy file is meant to grant system-wide codepermissions. Thejava.policy file installed with theSDK grants all permissions to standard extensions, allows anyone tolisten on un-privileged ports, and allows any code to read certain"standard" properties that are not security-sensitive, such as the"os.name" and "file.separator"properties.

The user policy file is by default located at

user.home/.java.policy  (Solaris)user.home\.java.policy  (Win32)

Note:user.home refers to the valueof the system property named "user.home", whichspecifies the user's home directory. On Win32 systems, given usernameuName, the "user.home"property value defaults to

C:\Winnt\Profiles\uName on multi-user Windows NT systemsC:\Windows\Profiles\uName on multi-user Windows 95 systemsC:\Windows on single-user Windows 95 systems

When the Policy is initialized, the system policy is loaded infirst, and then the user policy is added to it. If neither policyis present, a built-in policy is used. This built-in policy is thesame as the java.policy file installed with the JRE.

Policy file locations are specified in the security propertiesfile, which is located at

java.home/lib/security/java.security  (Solaris)java.home\lib\security\java.security  (Win32)

As noted above,java.home indicates thedirectory that houses the runtime environment--either thejre directory in the Java 2 SDK or the top-level directoryof the Java 2 Runtime Environment. The policy file locations arespecified as the values of properties whose names are of the form

policy.url.n

wheren is a number. You specify each suchproperty value in a line of the following form:

policy.url.n=URL

Here,URL is a URL specification.

For example, the default system and user policy files aredefined in the security properties file as

policy.url.1=file:${java.home}/lib/security/java.policypolicy.url.2=file:${user.home}/.java.policy

(SeeProperty Expansion forinformation about specifying property values via a special syntax,such as specifying thejava.home property valuevia${java.home}.)

You can actually specify a number of URLs (including ones of theform "http://"), and all the designated policy fileswill get loaded. You can also comment out or change the second oneto disable reading the default user policy file.

The algorithm starts atpolicy.url.1, and keepsincrementing until it does not find a URL. Thus if you havepolicy.url.1 andpolicy.url.3,policy.url.3 will never be read.

Specifying an Additional Policy File at Runtime

It is also possible to specify an additional or a differentpolicy file when invoking execution of an application. This can bedone via the "-Djava.security.policy" command lineargument, which sets the value of thejava.security.policy property. For example, ifyou use

    java -Djava.security.manager -Djava.security.policy=someURL SomeApp

wheresomeURL is a URL specifying the locationof a policy file, then the specified policy file will be loaded inaddition to all the policy files that are specified in the securityproperties file.

Notes:

• The URL can be any regular URL or simply the name of a policyfile in the current directory, as in

      java -Djava.security.manager -Djava.security.policy=mypolicy WriteFile

• The "-Djava.security.manager" argument ensuresthat the default security manager is installed, and thus theapplication is subject to policy checks. It is not required if theapplicationSomeApp installs a securitymanager.

If you use

    java -Djava.security.manager -Djava.security.policy==someURL SomeApp

(note the double equals) thenjust the specified policy filewill be used; all the ones indicated in the security propertiesfile will be ignored.

If you want to pass a policy file to the appletviewer, then usea "-J-Djava.security.policy" argument as follows:

    appletviewer -J-Djava.security.policy=someURL myApplet

Note:: The "-Djava.security.policy" policy filevalue will be ignored (for bothjava andappletviewer commands) if the"policy.allowSystemProperty" property in the securityproperties file is set to false. The default is true.

Changing thePolicy Implementation

An alternative policy class can be given to replace the Policyreference implementation class, as long as the former is a subclassof the abstract Policy class and implements thegetPermissions method (and other methods asnecessary).

The Policy reference implementation can be changed by editingthe security properties file, which is thejava.security file in thelib/securitydirectory of the SDK.

One of the types of properties you can set injava.security is of the following form:

    policy.provider=PolicyClassName

PolicyClassName must specify the fullyqualified name of the desiredPolicy implementationclass. The default security properties file entry for this propertyis the following:

    policy.provider=sun.security.provider.PolicyFile

To customize, you can change the property value to specifyanother class, as in

   policy.provider=com.mycom.MyPolicy

Policy FileSyntax

The policy configuration file(s) for an SDK installation specifywhat permissions (which types of system resource accesses) areallowed to code from a specified code source, and executed as aspecified principal.

For an applet (or an application running under a securitymanager) to be allowed to perform secured actions (such as readingor writing a file), the applet (or application) must be grantedpermission for that particular action. In the Policy referenceimplementation, that permission must be granted by a grant entry ina policy configuration file. See below and the"Java Security ArchitectureSpecification" for more information. (The only exception isthat code always automatically has permission to read files fromits same (URL) location, and subdirectories of that location; itdoes not need explicit permission to do so.)

A policy configuration file essentially contains a list ofentries. It may contain a "keystore" entry, and contains zero ormore "grant" entries.

KeystoreEntry

Akeystore is a database of private keys and theirassociated digital certificates such as X.509 certificate chainsauthenticating the corresponding public keys. Thekeytoolutility (forSolaris) (forWin32) is used to create and administer keystores. The keystorespecified in a policy configuration file is used to look up thepublic keys of the signers specified in the grant entries of thefile. A keystore entry must appear in a policy configuration fileif any grant entries specify signer aliases, or if any grantentries specify principal aliases (see below).

At this time, there can be only onekeystore/keystorePasswordURL entryin the policy file (other entries following the first one areignored). This entry can appear anywhere outside the file's grantentries. It has the following syntax:

keystore "some_keystore_url", "keystore_type", "keystore_provider";keystorePasswordURL "some_password_url";

some_keystore_url specifies the URL location of thekeystore,some_password_url specifies the URL locationof the keystore password,keystore_type specifies thekeystore type, andkeystore_provider specifies thekeystore provider. Note that the input stream fromsome_keystore_url is passed to theKeyStore.load method. IfNONE isspecified as the URL, then a null stream is passed to theKeyStore.load method.NONE should bespecified if theKeyStore is not file-based, forexample, if it resides on a hardware token device.

The URL is relative to the policy file location. Thus if thepolicy file is specified in the security properties file as:

    policy.url.1=http://foo.bar.com/fum/some.policy

and that policy file has an entry:

    keystore ".keystore";

then the keystore will be loaded from:

    http://foo.bar.com/fum/.keystore

The URL can also be absolute.

Akeystore type defines the storage and data format ofthe keystore information, and the algorithms used to protectprivate keys in the keystore and the integrity of the keystoreitself. The default type supported by Sun Microsystems is aproprietary keystore type named "JKS". Thus, if the keystore typeis "JKS", it does not need to be specified in the keystoreentry.

Grant Entries

Code being executed is always considered to come from aparticular "code source" (represented by an object of typeCodeSource). The code source includes not only thelocation (URL) where the code originated from, but also a referenceto the certificate(s) containing the public key(s) corresponding tothe private key(s) used to sign the code. Certificates in a codesource are referenced by symbolic alias names from the user'skeystore. Code is also considered to be executed as a particularprincipal (represented by an object of typePrincipal), or group of principals.

Eachgrant entry includes one or more "permissionentries" preceded by optionalcodeBase,signedBy, and principal name/value pairs that specifywhich code you want to grant the permissions. The basic format of agrant entry is the following:

  grant signedBy "signer_names", codeBase "URL",        principalprincipal_class_name "principal_name",        principalprincipal_class_name "principal_name",        ... {      permissionpermission_class_name "target_name", "action",           signedBy "signer_names";      permissionpermission_class_name "target_name", "action",           signedBy "signer_names";      ...  };

All non-italicized items above must appear as is (although casedoesn't matter and some are optional, as noted below). Italicizeditems represent variable values.

A grant entry must begin with the wordgrant.

TheSignedBy,Principal, andCodeBase Fields

ThesignedBy,codeBase, andprincipal values are optional, and the order of thesefields does not matter.

AsignedBy value indicates the alias for acertificate stored in the keystore. The public key within thatcertificate is used to verify the digital signature on the code;you grant the permission(s) to code signed by the private keycorresponding to the public key in the keystore entry specified bythe alias.

ThesignedBy value can be a comma-separated list ofmultiple aliases. An example is "Adam,Eve,Charles", which means"signed by Adam and Eve and Charles"; the relationship is AND, notOR. To be more exact, a statement like "Code signed by Adam" means"Code in a class file contained in a JAR which is signed using theprivate key corresponding to the public key certificate in thekeystore whose entry is aliased by Adam".

ThesignedBy field is optional in that, if it isomitted, it signifies "any signer". It doesn't matter whether thecode is signed or not or by whom.

A principal value specifies aclass_name/principal_name pair which mustbe present within the executing threads principal set. Theprincipal set is associated with the executing code by way of aSubject. The principal field is optional in that, if it is omitted,it signifies "any principals".

Noteon KeyStore Alias Replacement:

If the principal class_name/principal_name pair is specified asa single quoted string, it is treated as a keystore alias. Thekeystore is consulted and queried (via the alias) for an X509Certificate. If one is found, the principal class_name isautomatically treated asjavax.security.auth.x500.X500Principal, and theprincipal_name is automatically treated as the subjectdistinguished name from the certificate. If an X509 Certificatemapping is not found, the entire grant entry is ignored.

AcodeBase value indicates the code sourcelocation; you grant the permission(s) to code from that location.An emptycodeBase entry signifies "any code"; itdoesn't matter where the code originates from.

Note: acodeBase value is a URL and thusshould always utilize slashes (never backslashes) as the directoryseparator, even when the code source is actually on a Win32 system.Thus, if the source location for code on a Win32 system is actuallyC:\somepath\api\, then the policycodeBase entry should look like:

    grant codeBase "file:/C:/somepath/api/" {        ...    }

The exact meaning of acodeBase value depends on thecharacters at the end. AcodeBase with a trailing "/"matches all class files (not JAR files) in the specified directory.AcodeBase with a trailing "/*" matches all files(both class and JAR files) contained in that directory. AcodeBase with a trailing "/-" matches all files (bothclass and JAR files) in the directory and recursively all files insubdirectories contained in that directory. The following tableillustrates the different cases.

Codebase URL of Downloaded Code	Codebase URL in Policy	Match?
java.sun.com/people/gong/	java.sun.com/people/gong	Y
java.sun.com/people/gong/	java.sun.com/people/gong/	Y
java.sun.com/people/gong/	java.sun.com/people/gong/*	Y
java.sun.com/people/gong/	java.sun.com/people/gong/-	Y
java.sun.com/people/gong/appl.jar	java.sun.com/people/gong/	N
java.sun.com/people/gong/appl.jar	java.sun.com/people/gong/-	Y
java.sun.com/people/gong/appl.jar	java.sun.com/people/gong/*	Y
java.sun.com/people/gong/appl.jar	java.sun.com/people/-	Y
java.sun.com/people/gong/appl.jar	java.sun.com/people/*	N
java.sun.com/people/gong/	java.sun.com/people/-	Y
java.sun.com/people/gong/	java.sun.com/people/*	N

The Permission Entries

Apermission entry must begin with the wordpermission. The wordpermission_class_name in the template abovewould actually be a specific permission type, such asjava.io.FilePermission orjava.lang.RuntimePermission.

The "action" is required for many permissiontypes, such asjava.io.FilePermission (where itspecifies what type of file access is permitted). It is notrequired for categories such asjava.lang.RuntimePermission where it is notnecessary--you either have the permission specified by the"target_name" value following thepermission_class_name or you don't.

ThesignedBy name/value pair for a permission entryis optional. If present, it indicates a signed permission. That is,the permission class itself must be signed by the given alias(es)in order for the permission to be granted. For example, suppose youhave the following grant entry:

  grant {      permission Foo "foobar", signedBy "FooSoft";  }

Then this permission of typeFoo is granted if theFoo.class permission was placed in a JAR file and theJAR file was signed by the private key corresponding to the publickey in the certificate specified by the "FooSoft" alias, or ifFoo.class is a system class, since system classes arenot subject to policy restrictions.

Items that appear in a permission entry must appear in thespecified order (permission,permission_class_name, "target_name","action", andsignedBy "signer_names").An entry is terminated with a semicolon.

Case is unimportant for the identifiers(permission,signedBy,codeBase, etc.) but is significant for thepermission_class_name or for any string that is passed in asa value.

Note Regarding File Path Specifications on Win32 Systems

Note: When you are specifying ajava.io.FilePermission, the"target_name" is a file path. On Win32 systems,whenever you directly specify a file path in a string (but not in acodeBase URL), you need to include two backslashes for each actualsingle backslash in the path, as in

  grant {      permission java.io.FilePermission "C:\\users\\cathy\\foo.bat", "read";  };

The reason this is necessary is because the strings are processedby a tokenizer (java.io.StreamTokenizer), which allows"\" to be used as an escape string (for example,"\n" to indicate a new line) and which thus requirestwo backslashes to indicate a single backslash. After the tokenizerhas processed the above file path string, converting doublebackslashes to single backslashes, the end result is

    "C:\users\cathy\foo.bat"

Policy File Examples

An example of two entries in a policy configuration file is

  // If the code is signed by "Duke", grant it read/write access to all   // files in /tmp:  grant signedBy "Duke" {      permission java.io.FilePermission "/tmp/*", "read,write";  };  // Grant everyone the following permission:  grant {       permission java.util.PropertyPermission "java.vendor", "read";  };

The contents of another sample policy configuration file appearbelow.

  grant signedBy "sysadmin", codeBase "file:/home/sysadmin/*" {      permission java.security.SecurityPermission "Security.insertProvider.*";      permission java.security.SecurityPermission "Security.removeProvider.*";      permission java.security.SecurityPermission "Security.setProperty.*";  };

This specifies thatonly code that satisfies the followingconditions can call methods in the Security class to add or removeproviders or to set Security properties:

• The code was loaded from a signed JAR file that is in the"/home/sysadmin/" directory on the local filesystem.
• The signature can be verified using the public key referencedby the alias name "sysadmin" in the keystore.

Either component of the code source (or both) may be missing. Anexample wherecodeBase is missing is:

  grant signedBy "sysadmin" {      permission java.security.SecurityPermission "Security.insertProvider.*";      permission java.security.SecurityPermission "Security.removeProvider.*";  };

If this policy is in effect, code that comes in a JAR File signedby "sysadmin" can add/remove providers, regardless of where the JARFile originated from.

An example without a signer is:

  grant codeBase "file:/home/sysadmin/-" {      permission java.security.SecurityPermission "Security.insertProvider.*";      permission java.security.SecurityPermission "Security.removeProvider.*";  };

In this case, code that comes from anywhere beneath the"/home/sysadmin/" directory on the local filesystemcan add/remove providers. The code does not need to be signed.

An example where neithercodeBase norsignedBy is included is:

  grant {      permission java.security.SecurityPermission "Security.insertProvider.*";      permission java.security.SecurityPermission "Security.removeProvider.*";  };

Here, with both code source components missing, any code(regardless of where it originated from, or whether or not it issigned, or who signed it) can add/remove providers.

The following represents a principal-based entry.

  grant principal javax.security.auth.x500.X500Principal "cn=Alice" {      permission java.io.FilePermission "/home/Alice", "read, write";  };

This permits any code executing as the X500Principal,"cn=Alice", permission to read and write to"/home/Alice".

The following example shows a grant statement with bothcodesource and principal information.

  grant codebase "http://www.games.com",        signedBy "Duke",        principal javax.security.auth.x500.X500Principal "cn=Alice" {      permission java.io.FilePermission "/tmp/games", "read, write";  };

This allows code downloaded from "www.games.com",signed by "Duke", and executed by"cn=Alice", permission to read and write into the"/tmp/games" directory.

The following example shows a grant statement with KeyStorealias replacement:

  keystore "http://foo.bar.com/blah/.keystore";  grant principal "alice" {      permission java.io.FilePermission "/tmp/games", "read, write";  };

"alice" will be replaced by

javax.security.auth.x500.X500Principal"cn=Alice"

assuming the X.509 certificate associated with the keystore alias,alice, has a subject distinguished name of"cn=Alice". This allows code executed by theX500Principal "cn=Alice" permission to read and writeinto the "/tmp/games" directory.

Property Expansion inPolicy Files

Property expansion is possible in policy files and inthe security properties file.

Property expansion is similar to expanding variables in a shell.That is, when a string like

    ${some.property}

appears in a policy file, or in the security properties file, itwill be expanded to the value of the system property. For example,

    permission java.io.FilePermission "${user.home}", "read";

will expand "${user.home}" to use the value of the"user.home" system property. If that property's value is"/home/cathy", then the above is equivalent to

    permission java.io.FilePermission "/home/cathy", "read";

In order to assist in platform-independent policy files, you canalso use the special notation of "${/}", which is ashortcut for "${file.separator}". This allows thingslike

    permission java.io.FilePermission "${user.home}${/}*", "read";

If the value of the "user.home" property is/home/cathy, and you are on Solaris, the above getsconverted to:

    permission java.io.FilePermission "/home/cathy/*", "read";

If on the other hand the "user.home" value isC:\users\cathy and you are on a Win32 system, theabove gets converted to:

    permission java.io.FilePermission "C:\users\cathy\*", "read";

Also, as a special case, if you expand a property in a codebase,such as

    grant codeBase "file:${java.home}/lib/ext/"

then any file.separator characters will be automatically convertedto/'s. Thus on a Win32 system, the above would getconverted to

    grant codeBase "file:C:/jdk1.4/jre/lib/ext/"

even if "java.home" is set toC:\jdk1.4\jre. Thus you don't need to use${/} in codebase strings (and you shouldn't).

Property expansion takes place anywhere a double quoted stringis allowed in the policy file. This includes the"signer_names","URL","target_name", and"action"fields.

Whether or not property expansion is allowed is controlled bythe value of the "policy.expandProperties" property inthe security properties file. If the value of this property is true(the default), expansion is allowed.

Note: You can't use nested properties; they will notwork. For example,

    "${user.${foo}}"

doesn't work, even if the "foo" property is set to"home". The reason is the property parser doesn'trecognize nested properties; it simply looks for the first"${", and then keeps looking until it finds the first"}" and tries to interpret the result (in this case,"${user.$foo}") as a property, but fails if there isno such property.

Note: If a property can't be expanded in a grant entry,permission entry, or keystore entry, that entry is ignored. Forexample, if the system property "foo" is not definedand you have:

    grant codeBase "${foo}" {        permission ...;        permission ...;    };

then all the permissions in this grant entry are ignored. If youhave

    grant {        permission Foo "${foo}";        permission Bar "barTarget";    };

then only the "permission Foo..." entry is ignored.And finally, if you have

    keystore "${foo}";

then the keystore entry is ignored.

Win32 Systems, File Paths, and Property Expansion

As noted above, on Win32 systems, when you directlyspecify a file path in a string (but not in a codeBase URL), youneed to include two backslashes for each actual single backslash inthe path, as in

    grant {        permission java.io.FilePermission "C:\\users\\cathy\\foo.bat", "read";    };

This is because the strings are processed by a tokenizer(java.io.StreamTokenizer), which allows"\" to be used as an escape string (e.g.,"\n" to indicate a new line) and which thus requirestwo backslashes to indicate a single backslash. After the tokenizerhas processed the above file path string, converting doublebackslashes to single backslashes, the end result is

    "C:\users\cathy\foo.bat"

Expansion of a property in a string takes place after the tokenizerhas processed the string. Thus if you have the string

    "${user.home}\\foo.bat"

then first the tokenizer processes the string, converting thedouble backslashes to a single backslash, and the result is

    "${user.home}\foo.bat"

Then the${user.home} property is expanded and the endresult is

    "C:\users\cathy\foo.bat"

assuming the "user.home" value isC:\users\cathy. Of course, for platform independence,it would be better if the string was initially specified withoutany explicit slashes, i.e., using the${/} propertyinstead, as in

    "${user.home}${/}foo.bat"

General Expansion inPolicy Files

Generalized forms of expansion are also supported inpolicy files. For example, permission names may contain a string ofthe form:

${{protocol:protocol_data}}

If such a string occurs in a permission name, then the value inprotocol determines the exact type of expansion that shouldoccur, andprotocol_data is used to help perform theexpansion.protocol_data may be empty, in which case theabove string should simply take the form:

${{protocol}}

There are two protocols supported in the default policy fileimplementation:

1. ${{self}}

   The protocol,self, denotes a replacement ofthe entire string,${{self}}, with one or moreprincipal class/name pairs. The exact replacement performed dependsupon the contents of the grant clause to which the permissionbelongs.

   If the grant clause does not contain any principal information,the permission will be ignored (permissions containing${{self}} in their target names are only valid in thecontext of a principal-based grant clause). For example,BarPermission will always be ignored in the followinggrant clause:

               grant codebase "www.foo.com", signedby "duke" {                permission BarPermission "... ${{self}} ...";            };

   If the grant clause contains principal information,${{self}} will be replaced with that same principalinformation. For example,${{self}} inBarPermission will be replaced withjavax.security.auth.x500.X500Principal"cn=Duke" in the following grant clause:

   grant principal javax.security.auth.x500.X500Principal "cn=Duke" {    permission BarPermission "... ${{self}} ...";};

   If there is a comma-separated list of principals in the grantclause, then${{self}} will be replaced by the samecomma-separated list or principals. In the case where both theprincipal class and name are wildcarded in the grant clause,${{self}} is replaced with all the principalsassociated with theSubject in the currentAccessControlContext.

   The following example describes a scenario involving bothself andKeyStore alias replacementtogether:

   keystore "http://foo.bar.com/blah/.keystore";grant principal "duke" {    permission BarPermission "... ${{self}} ...";};

   In the above example, "duke" will first be expandedintojavax.security.auth.x500.X500Principal"cn=Duke" assuming the X.509 certificate associated withtheKeyStore alias, "duke", has a subjectdistinguished name of "cn=Duke". Next,${{self}} will be replaced with the same principalinformation that was just expanded in the grant clause:javax.security.auth.x500.X500Principal"cn=Duke".
2. ${{alias:alias_name}}

   The protocol,alias, denotes ajava.security.KeyStore alias substitution. TheKeyStore used is the one specified in theKeyStore entry.alias_namerepresents an alias into theKeyStore.${{alias:alias_name}} is replaced withjavax.security.auth.x500.X500Principal "DN",whereDN represents the subject distinguishedname of the certificate belonging toalias_name. For example:

   keystore "http://foo.bar.com/blah/.keystore";grant codebase "www.foo.com" {    permission BarPermission "... ${{alias:duke}} ...";};

   In the above example the X.509 certificate associated with thealias,duke, is retrieved from theKeyStore,foo.bar.com/blah/.keystore. Assuming duke'scertificate specifies "o=dukeOrg, cn=duke" as thesubject distinguished name, then${{alias:duke}} isreplaced withjavax.security.auth.x500.X500Principal"o=dukeOrg, cn=duke".

   The permission entry is ignored under the following errorconditions:

   • The keystore entry is unspecified
   • Thealias_name is not provided
   • The certificate foralias_name can not beretrieved
   • The certificate retrieved is not an X.509 certificate

RelatedDocumentation

• Permissions in Java 2 SDK
• Policy Tool (forSolaris) (forWin32)

Contact Us