Internal Structure
The J2SE Policy Provider that supports XACML in this recommended approach can be implemented as follows, using Sun's XACML Implementation [1]:

                      |   ^
                      |   |
                  J2SE Policy API
                      |   |
                  ____V___|_______
                 | PDP Interface  |
                 | Module         |<---------------
                 |________________|               |
                      |   ^                       |
                      |   |                       |
                   PDP.evaluate() API             |
                      |   |                       |
________________ ____V___|_______           _____|____________
| J2SE-specific  | Sun's XACML    |-------->| J2SE-Specific    |
| DataTypes and  | Implementation |         | Attribute Finder |
| Functions      |                |         | Module           |
|________________|________________|         |__________________|
                        |
                  ______V_________
                 | Other Finder   |_
                 | Modules        | |_
                 |________________| | |
                   |________________| |
                     |________________|              

This proposal makes use of Sun's XACML Implementation support for pluggable "Attribute Finder Modules" that know how to retrieve specific attributes from various repositories. It also makes use of the ability to add support for new DataTypes and FunctionIds easily.

The components of this structure are explained in the subsequent sections.

PDP Interface Module
The PDP Interface Module acts as an intermediary between the J2SE Policy API and its information model and Sun's XACML Implementation [1] PDP APIs. It translates an invocation of the J2SE Policy.implies() method into an XACML PDP.evaluate() invocation. Likewise, the PDP maps the ResponseCtx output from the XACML PDP to a return value of "True" if the Response.Decision is Permit, and to a return value of "False" otherwise.

The PDP Interface Module also allows the J2SE-Specific Attribute Finder Module access to objects passed via the Policy API.

J2SE-Specific Attribute Finder Module
This module performs the mapping between objects passed via the J2SE Policy API and various XACML Attributes. Rather than trying to construct an instance of the XACML Request schema, it supplies appropriate values dynamically. When an XACML Attribute is requested via the PDP's AttributeFinder.findAttribute() method, this Finder Module invokes the corresponding Policy API objects via the PDP Interface Module. It then modifies the resulting values as appropriate, and returns the corresponding results, caching results as appropriate. The AttributeIds supported by this module are described in the AttributeIds section of this proposal.

Additional AttributeIds can be supported by other Attribute Finder Modules. For example, support for several Environment Attributes such as the current date and time are built into Sun's XACML Implementation, allowing J2SE Applications to make use of policies that allow different permissions based on the time of day. Other attributes of the environment, such as the day of the week, can be provided by new modules. Other attributes of a subject, such as various roles, can be retrieved from an external repository indexed by the subject identity. Resource labels on the resource being accessed can be accessed from an external repository indexed by the resource identity. This extensibility is part of the design of the XACML policy language.

Policy API Support
This section describes how the J2SE XACML Policy Provider supports the specific methods in the J2SE Policy API.

The java.security.Policy Class is the abstract base class that exports the Policy API.

It supports the following methods:

boolean       implies(ProtectionDomain domain, Permission
permission)
abstract PermissionCollection
              getPermissions(CodeSource codesource)
PermissionCollection
              getPermissions(ProtectionDomain domain)
static Policy getPolicy()
static void   setPolicy(Policy policy)
abstract void refresh()
The getPolicy and setPolicy methods are handled by the abstract class. This section recommends ways to support the remaining methods in the J2SE XACML Policy Provider.

implies
In the recommended internal structure described above, the PDP Interface Module of the XACML Policy Provider implements the Policy.implies() method. It does this by invoking the PDP.evaluate() method exported by Sun's XACML Implementation. When the PDP, in evaluating an XACML Policy, encounters an XACML AttributeDesignator with an AttributeId that has been mapped to information provided in the Policy API, this AttributeId is handled by the J2SE-Specific Attribute Finder Module (provided via a pluggable interface exported from Sun's XACML Implementation). This Attribute Finder Module in turn invokes the PDP Interface Module, which make the appropriate method calls on the Policy API objects, and returns the requested information. The J2SE-Specific Attribute Finder Module modifies this information as needed, and then returns the appropriate information to the PDP.

The preceding sections of this Proposal describe the specific mappings that are performed.

The PDP Interface Module could try to maintain a cache of PermissionCollections indexed by ProtectionDomain and representing previously requested Permissions that have evaluated to "Permit" for the indexed ProtectionDomain. The Interface Module would need to screen out Permissions that were obtained based on time of day or other dynamic attributes, and this may be difficult to implement. If a safe cache can be created, then before invoking the PDP.evaluate() API, the PDP Interface Module can test a requested Permission against any PermissionCollection located in this cache for the input ProtectionDomain.

getPermissions
This proposal recommends that the XACML Policy Provider return an empty PermissionCollection as the result of the two Policy.getPermissions methods. For more information on this recommendation, see the getPermissions discussion in the Issues and Rationale Section.

refresh
The XACML Policy Provider can implement the Policy.refresh method by clearing its cache of retrieved Policy and PolicySet instances, and by retrieving a fresh copy of its base policy, if appropriate. Any cache of previously evaluated Permissions should also be cleared.

PolicyFile to XACML Translator
In order to protect customer investment in existing PolicyFile policies, this proposal includes a tool that translates PolicyFile policies into equivalent XACML policies. This tool can be completely automatic [with exception of property expansion?], since PolicyFile semantics can be captured precisely in XACML.

This translator makes the following translations.

A PolicyFile grant statement has the following general syntax:

grant [signedBy signer_name, ...] [, codebase URL],
      [principal principal_class_name principal_name]...
{
  permission permission_class_name target_name,
             [action] [, signedBy signer_name...]
  ...
}

Each grant statement is translated into one XACML Rule. Each type of phrase in the grant statement generates one <Apply> element in the Rule's <Condition> as follows.

<Rule RuleId="[UNIQUE-ID]" Effect="Permit">
  <Condition FunctionId="and">

    <!-- each grant ... signedBy [ALIAS] generates -->

    <Apply FunctionId="j2se#function:certificate-is-in">
      <Apply FunctionId="j2se#function:getCertificateFromKeyStore">
        <AttributeValue DataType="string">[ALIAS]</AttributeValue>
        <!-- from required 'keystore "[URL]" "[TYPE]"' -->
        <AttributeValue
           DataType="anyURI">[URL]</AttributeValue>
        <AttributeValue
           DataType="string">[TYPE]</AttributeValue>
      </Apply>
      <SubjectAttributeDescriptor
         AttributeId="j2se#attribute:signerCertificate"
         SubjectCategory="codebase"
         DataType="j2se#class:java.security.Certificate"/>
      </SubjectAttributeDescriptor>
    </Apply>

    <!-- each grant ... codeBase "[URL]" generates -->

    <Apply FunctionId="anyURI-is-in">
      <AttributeValue DataType="anyURI">[URL]>
      <SubjectAttributeDescriptor
         AttributeId="subject:subject-id"
         SubjectCategory="codebase"
         DataType="anyURI"/>
    </Apply>

    <!-- each grant ... principal "[ALIAS]" generates -->

    <Apply FunctionId="x500Name-is-in">
      <Apply FunctionId="j2se#method:getSubjectDN">
        <Apply FunctionId="j2se#function:getCertificateFromKeyStore">
        <AttributeValue DataType="string">[ALIAS]</AttributeValue>
        <!-- from required 'keystore "[URL]" "[TYPE]"' -->
        <AttributeValue
           DataType="anyURI">[URL]</AttributeValue>
        <AttributeValue
           DataType="string">[TYPE]</AttributeValue>
      </Apply>
      <SubjectAttributeDescriptor
         AttributeId="subject:subject-id"
         SubjectCategory="access-subject"
         DataType="x500Name"/>
    </Apply>

    <!-- each grant ... principal [CLASS] "[NAME]" generates -->

    <Apply FunctionId="string-is-in">
      <AttributeValue
         DataType="string">[NAME]</AttributeValue>
      <Apply FunctionId="map">
          <Apply FunctionId="j2se#method:getName">
            <SubjectAttributeDesignator
               AttributeId="subject:subject-id"
               DataType="j2se#class:[CLASS]"
          </Apply>
      </Apply>
    </Apply>

    <Apply FunctionId="or">

      <!-- each
          permission [CLASS] "[TARGET]", "[ACTIONS] signedBy "[ALIAS]"
          generates -->

      <Apply FunctionId="and">

        <Apply
           FunctionId="j2se#method:implies">
          <AttributeValue
             DataType="j2se#class:[CLASS]">
             <AttributeValue
                DataType="string">[TARGET]</AttributeValue>
             <!-- following AttributeValue omitted if no
                 [ACTIONS] -->
             <AttributeValue
                DataType="string">[ACTIONS]</AttributeValue>
          </AttributeValue>
          <Apply FunctionId="j2se#function:permission-one-and-only">
            <ResourceAttributeDesignator
               AttributeId="resource:resource-id"
               DataType="j2se#class:java.security.Permission"
          </Apply>
        </Apply>

        <!-- following Apply omitted if no signedBy "[ALIAS]" -->
        <Apply FunctionId="j2se#function:certificate-is-in">
          <Apply FunctionId="j2se#function:getCertificateFromKeyStore">
            <AttributeValue DataType="string">[ALIAS]</AttributeValue>
            <!-- from required 'keystore "[URL]" "[TYPE]"' -->
            <AttributeValue
               DataType="anyURI">[URL]</AttributeValue>
            <AttributeValue
               DataType="string">[TYPE]</AttributeValue>
          </Apply>
          <ResourceAttributeDescriptor
             AttributeId="j2se#attribute:signerCertificate"
             DataType="j2se#class:java.security.Certificate"/>
        </Apply>

      </Apply>

    </Apply>
  </Condition>
</Rule>

See Appendix 1: Example of a Translated Simple PolicyFile and Example of a Translated Full PolicyFile for examples.

Issues and Rationale
This section describes some areas of particular difficulty encountered when trying to map the semantics of the J2SE Policy API or PolicyFile into XACML.

getPermissions
The XACML PDP defined in the XACML 1.0 standard does not have any interface that returns the equivalent of a set of permissions. For this reason, it is not possible to implement the two Policy.getPermissions() methods directly using XACML.

In XACML, a Policy is evaluated on the basis of attributes of the subjects, resources, and actions, returning a result of "Permit" or "Deny", "Indeterminate", or "NotApplicable". XACML policies are not designed to allow easy extraction of a static collection of resources and associated actions "permitted" for a given set of subject attributes. In fact, many XACML policies would not be able to return a set of permitted resources and actions, since the set would only be permitted at certain times of day or under combinations of conditions that can not be captured in a simple set of attributes.

Work is now in progress within the XACML TC to define a way of evaluating an XACML policy in order to return a set of Attribute values. Since this work is very preliminary, and will probably use a very constrained form of the XACML syntax, it should not be considered a solution to the problem of supporting a PermissionCollection as returned from getPermissions.

Some existing custom Policy Providers return a live PermissionCollection that does not encapsulate a specific collection of individual permissions. The implies method of such a PermissionCollection is used to test specific Permission requests dynamically. In such cases, the PermissionCollection that is returned may not be an instance of the Permissions class. Such live PermissionCollection objects typically do not support the elements method.

The XACML Policy Provider could support the getPermissions() methods using such a custom PermissionCollection. For example, it could return an XACMLPermissionCollection subclass that encapsulates the ProtectionDomain or CodeSourcefor which the request was made. This subclass would implement its implies(Permission) method by invoking the Policy.implies() method, causing a full XACML policy evaluation to occur. If new Permission instances are added to the XACMLPermissionCollection, they could be saved in an internal PermissionCollection that would be tested before invoking Policy.implies(). (Note that this technique would not support the overlapping Permissions semantics of a PermissionCollection).

In order to support the return of individual Permissions from XACMLPermissionCollection.elements() API, the XACMLPermissionCollection could return a single element consisting of a custom Permission subclass instance. This XACMLPermission subclass would store its associated ProtectionDomain or CodeSource as a class variable. When its implies(Permission) method was invoked, XACMLPermission would use its cached ProtectionDomain or CodeSource, along with the Permission passed as the argument to the implies method, to invoke Policy.implies. XACMLPermission would have to be compatible with all other Permission and PermissionCollection subclasses in order to allow an XACMLPermission to be included inside any homogeneous or heterogeneous PermissionCollection.

While it would be possible to support the getPermissions methods using such a technique, this proposal recommends that we not try to do so. This recommendation is made in light of the ways in which the PermissionCollection returned from getPermissions is used.

The PermissionCollection returned by the getPermissions(ProtectionDomain) method is used by the standard ClassLoader to obtain Permission objects that have been granted to a particular ProtectionDomain, independent of any Principal objects that may later be combined with the ProtectionDomain. These Permission objects are stored in the ProtectionDomain. At runtime, this cache of pre-evaluated, static Permissions is used as an optimization. If a requested Permission is implied by the PermissionCollection stored in the ProtectionDomain, then the Permission is granted. Otherwise, the Policy.implies() method is invoked to make use of any Permissions that depend on Principal associations or on Permissions that may have been added to the policy since the ClassLoader obtained the static set.

The result of evaluating an XACMLPermissionCollection would be exactly equivalent to the result of evaluating Policy.implies. A cached PermissionCollection in the ProtectionDomain implies that these are pre-evaluated, or optimized Permissions, but, in the case of XACML, this is not the case. Thus it seems more direct to return an empty PermissionCollection from Policy.getPermissionCollection, forcing all run-time evaluations to use the Policy.implies API.

One more difficulty with trying to support Policy.getPermissions as described above is that the combine method of the JAAS SubjectDomainCombiner does not preserve custom PermissionCollections. This means the late binding effects would be extinguished by this combiner. Solving this problem would require creating and using a custom DomainCombiner that would preserve the custom XACMLPermissionCollection. Again, it just seems more straightforward to force use of Policy.implies() at runtime.

Overlapping Permissions
An issue closely related to that of implementing the Policy.getPermissions methods is the issue of supporting overlapping Permissions in a PermissionCollection with XACML.

The J2SE Policy model is somewhat different from the XACML Policy model. In the J2SE platform, a Policy is evaluated on the basis of the attributes of the subjects (ProtectionDomain) making the request to return a collection of the resources and associated actions (PermissionCollection) to which the subjects have access. Each requested Permission is then evaluated against this PermissionCollection to return a result of "True" (grant access) or "False" (deny access).

A requested Permission may be granted by a PermissionCollection even if it is not implied by any single Permission in the collection. One simple example of this behavior is a J2SE policy that grants a particular subject access to two different FilePermissions for a given file: one with action "read, delete", and the other with action "write". If the subject requests permission to "read, write" this file, this request is granted because the aggregate PermissionCollection recognizes that the two individual Permission actions can be merged into a set of actions, of which the requested action is a subset.

This aggregate behavior of Permissions in a PermissionCollection is referred to as overlapping Permissions.

There are few constraints on how Permission subclasses implement this aggregate behavior. There can be complex interactions not only between different Permissions of the same subclass, but even interactions between Permissions of different subclasses.

The following preliminary proposal describes one potential way of supporting overlapping Permissions in an XACML J2SE Policy Provider. Comments are invited.

This approach to handling overlapping Permissions is based on the observation that, when an XACML Rule is in Disjunction Normal Form (an OR of AND predicates), then all the Permission objects used in a single AND predicate can be collected into a single PermissionCollection. This PermissionCollection captures any overlapping Permission semantics that should be allowed to affect the evaluation of the Rule. The procedure is as follows.

Put the XACML Rule into Disjunctive Normal Form. See [9] for a nice description of the standard algorithm. Start evaluation of the Rule.

When evaluating each AND predicate, first create a new Permissions object. Whenever an expression of the form

<Apply FunctionId="j2se#method:implies">
  <AttributeValue DataType="j2se#class:X">
     [constructor arguments]
  </AttributeValue>
  <ResourceAttributeDesignator AttributeId="resource-id"
                     DataType="j2se#class:Y"/>
</Apply>

is encountered in the AND predicate, where X and Y are subclasses of java.security.Permission, construct a new Permission object from the AttributeValue. Pass this new Permission object to the add method of the Permissions object. Now treat the original Apply expression as if it had evaluated to "true".

At the end of evaluation of the AND predicate, if the result is "true" so far, then invoke the implies method of the Permissions object, passing it the requested Permission object. If this method returns "true", then the AND predicate evaluates to "true" and the Rule evaluation can terminate by returning the specified Effect. Otherwise, the AND predicate evaluates to "false", and evaluation of the next AND predicate begins with creation of a new, empty Permissions object.

This proposal recommends that overlapping Permissions not be supported for the first release of the XACML Policy Provider due to the difficulty of implementing support for these complex semantics.

KeyStores
In PolicyFile, a keystore entry is a way to reference a cache of certificates. A keystore entry may occur anywhere outside the PolicyFile's grant entries. There can be only one keystore entry per policy file. This entry specifies the J2SE keystore location and type to be used in resolving keystore aliases encountered in the PolicyFile's grant entries.

Keystore aliases may be used in PolicyFile to specify the following.

signedBy fields

The public key certificate associated with the alias is retrieved and matched against the "signer" certificates associated with a ProtectionDomain, either that of the requested Permission class or the ProtectionDomain of the application Class object that made the access request.

principal entries

The subject distinguished name is retrieved from the public key certificate associated with the alias; the certificate is assumed to be of type java.security.cert.X509Certificate

A new J2SE-specific AttributeId has been proposed above to reference either the signer certificates for the codebase class or the signer certificates for the requested Permission class.

The problem is in how, in XACML, to specify certificates located in a keystore for use in comparing with the certificates referenced by this AttributeId.

This proposal recommends specifying the location and type of the keystore file as an argument to each invocation of a new getCertificateFromKeyStore function.

An alternative solution would be some sort of setKeyStore function taking as arguments the location and type of the keystore. Such a function would return true if a keystore of the specified type could be accessed at the specified location. As a side-effect, the function would establish the keystore to be used by invocations of the getCertificateFromKeyStore function within some specified scope.

While it is inconvenient to have to specify the keystore location and type each time a certificate is retrieved, the use of side effects to establish state is not good language design and violates the stateless nature of other XACML constructs.

The use of a keystore alias to express a "principal" name is just a convenience, saving the user from typing out the entire name. If this functionality is important, it can be accomplished by using the new j2se#function:getCertificateFromKeyStore function, and using the result as the argument to an invocation of the j2se#method:getSubjectDN function. It does not seem worth the clutter to define a new j2se#function:getPrincipalFromKeyStoreAlias function, although this is certainly possible to do.

Multiple Actions
In the J2SE platform, a requested Permission may contain more than one "action" to be performed. For example, a FilePermission may contain an action of "read, write". XACML, however, does not support multiple actions in a single policy evaluation request.

This proposal recommends that instances of certain standard Permission subclasses, such as java.io.FilePermission and java.net.SocketPermission, be recognized by the PDP Interface Module and tested for multiple actions. When multiple actions are being requested, the PDP Interface Module submits a separate Request to the PDP.evaluate() API for each action in the list. The PDP Interface Module returns "True" as the Policy API response only if ALL such evaluations result in "Permit".

Policies that compare a Permission using the j2ee#method:implies function handle multiple actions correctly.

Multiple actions per Permission will be supported otherwise only if custom code is added to the J2SE-extended XACML PDP implementation for each such Permission subclass.

Property Expansion
PolicyFile supports a syntax within literal value strings that allows the value of a J2SE Property to be inserted at that point in the value. For example,

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

becomes

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

if the current value of the user.home system property is "/home/cathy".

This could be handled directly in several ways.

Extend the XACML PDP to support a syntax for embedding the value retrieved by one AttributeDescriptor inside a literal AttributeValue. For example, ${Subject, j2se#attribute:user.home, string, access-subject} could be expanded to insert the value of the <SubjectAttributeDesignator> with AttributeId="j2se#attribute:user.home", DataType="http://www.w3.org/2001/XMLSchema#string", and SubjectCategory="access-subject" into the literal value where this expression occurred (assuming there is only one Attribute that matches this Designator).

Extend the XACML PDP to support J2SE ${some.property} syntax inside literal values.

Define J2SE-specific functions for comparing values in which such expressions might occur such that they recognize and expand these expressions.

This proposal recommends the last method - providing J2SE-specific functions - and specifically proposes implementing such expansion capability in the j2se#function:file-path-match function. Extending the XACML PDP to recognize any sort of AttributeId insertion should be done in a standardized way for XACML as a whole. Confining the use of an expansion syntax to J2SE-specific functions avoids having policies use a syntax for general attributes that is not supported on all platforms.

General Expansion
PolicyFile supports another expansion syntax called "General Expansion". It is presented as a general expansion syntax, but actually only two types of substitution are allowed: a way of referring to the X.500 Distinguished Name of a Principal in the ProtectionDomain involved in making the access request, and a way of substituting an X.500 Distinguished Name taken from a certificate in a keystore.

This proposal recommends that this functionality not be implemented in the first release of the J2SE XACML Policy Provider. Based on actual customer requirements, this functionality could be supported within literal values used with J2SE-specific functions in a later release. As with the Property Expansion syntax described above, this functionality is too specific to the J2SE platform for the XACML PDP itself to be expanded to recognize this syntax in general.

--------------------------------------------------------------------------------

References
[1] Sun's XACML Implementation , an Open Source BSD License implementation of XACML.

[2] OASIS XACML Version 1.0 Standard Specification , 18 February 2003.

[3] OASIS XACML Version 1.0 Policy Schema, 18 February 2003.

[4] OASIS XACML Version 1.0 Request and Response Context Schema , 18 February 2003.

[5] Default Policy Implementation and Policy File Syntax, 20 April 2002.

[6] Permissions in the Java[TM] 2 SDK.

[7] Java[TM] Access Control Mechanisms, by Anne Anderson, Sun Microsystems Laboratories Technical Report #2002-0134, Mar 15, 2002.

[8] XACML RBAC Profile, profile for use of XACML with role based access control policies, Working Draft 01, 5 June 2003.

[9] KeyNote Policy Files and Conversion to Disjunctive Normal Form for Use in IPsec , by E. Spyropoulou, et al., Center for Information Systems Security Studies and Research, Computer Science Department, Naval Postgraduate School, Monterey, CA, January 2002.

[10] A Brief Introduction to XACML , 14 March 2003.

Contributors
The following individuals contributed valuable suggestions to this proposal. Any errors in the proposal, however, are solely the responsibility of the author.

Gary Ellison
Steve Hanna
Charlie Lai
Ron Monzillo
Seth Proctor

--------------------------------------------------------------------------------

Appendix 1: Example of a Translated Simple PolicyFile
This appendix contains a PolicyFile and its expression as an equivalent XACML Policy. The PolicyFile is very simple, and uses only the basic syntax. For a more elaborate example, see Example of a Translated Full PolicyFile.

The translation was done manually, and so may contain errors. Standard XACML URNs and "wordy" syntax have been shortened slightly to make this example more readable, but anyone familiar with XACML should be able to convert this to a schema-compliant form easily.

PolicyFile
The simple example PolicyFile follows.

grant codeBase "http://my/classes"
{
      permission java.io.FilePermission "/tmp/games",
                                        "read, write"
};

XACML Policy
The same policy expressed using the XACML syntax, and making use of the extensions in this proposal, follows.

<Policy PolicyId="a1bc2f890" RuleCombiningAlgId="permit-overrides">

  <Target>
    <Subjects><AnySubject/></Subjects>
    <Resources><AnyResource/></Resources>
    <Actions><AnyAction/></Actions>
  </Target>        

  <Rule RuleId="a1bc2f890.1" Effect="Permit">
    <Condition FunctionId="and">

      <!-- grant codeBase "http://my/classes" -->

      <Apply FunctionId="anyURI-is-in">
        <AttributeValue
           DataType="anyURI">http://my/classes</AttributeValue>
        <SubjectAttributeDescriptor
           AttributeId="subject:subject-id"
           SubjectCategory="codebase"
           DataType="anyURI"/>
      </Apply>

      <Apply FunctionId="or">
  
        <!-- "and" in case "permission ... signedBy" -->
        <Apply FunctionId="and">

          <!-- permission java.io.FilePermission
                          "/tmp/games", "read, write", -->

          <Apply
             FunctionId="j2se#method:implies">
            <AttributeValue
               DataType="j2se#class:java.io.FilePermission">
               <AttributeValue
                  DataType="string">/tmp/games</AttributeValue>
               <AttributeValue
                  DataType="string">read, write</AttributeValue>
            </AttributeValue>
            <Apply FunctionId="j2se#function:permission-one-and-only">
              <ResourceAttributeDesignator
                 AttributeId="resource:resource-id"
                 DataType="j2se#class:java.security.Permission"
            </Apply>
          </Apply>
        </Apply>

      </Apply>

    </Condition>
  </Rule>
</Policy>

--------------------------------------------------------------------------------

Appendix 2: Example of a Translated Full PolicyFile
This appendix contains a PolicyFile and its expression as an equivalent XACML Policy. The PolicyFile uses every type of PolicyFile syntax possible, so is rather complex. For a simpler example, see Example of a Translated Simple PolicyFile.

The translation was done manually, and so may contain errors. Standard XACML URNs and "wordy" syntax have been shortened slightly to make this example more readable, but anyone familiar with XACML should be able to convert this to a schema-compliant form easily.

PolicyFile
The example PolicyFile follows.

keystore "file:/opt/keystores/.keystore" "JKS";

grant codeBase "http://my/classes"
{
      permission java.io.FilePermission "/tmp/games",
                                        "read, write"
};

grant signedBy "duke,sysadmin",
      codeBase "http://my/classes",
      principal "bob",
      principal javax.security.auth.x500.X500Principal "cn=Alice"
{
      permission java.io.FilePermission "/tmp/games",
                                        "read, write",
           signedBy "FooSoft";
      permission java.security.SecurityPermission "Security.insertProvider.*";
};

XACML Policy
The same policy expressed using the XACML syntax, and making use of the extensions in this proposal, follows.

<Policy PolicyId="f234ab56c" RuleCombiningAlgId="permit-overrides">

  <Target>
    <Subjects><AnySubject/></Subjects>
    <Resources><AnyResource/></Resources>
    <Actions><AnyAction/></Actions>
  </Target>        

  <Rule RuleId="f234ab56c.1" Effect="Permit">
    <Condition FunctionId="and">

      <!-- grant codeBase "http://my/classes" -->

      <Apply FunctionId="anyURI-is-in">
        <AttributeValue
           DataType="anyURI">http://my/classes</AttributeValue>
        <SubjectAttributeDescriptor
           AttributeId="subject:subject-id"
           SubjectCategory="codebase"
           DataType="anyURI"/>
      </Apply>

      <Apply FunctionId="or">
  
        <!-- "and" in case "permission ... signedBy" -->
        <Apply FunctionId="and">

          <!-- permission java.io.FilePermission
                          "/tmp/games", "read, write", -->

          <Apply
             FunctionId="j2se#method:implies">
            <AttributeValue
               DataType="j2se#class:java.io.FilePermission">
               <AttributeValue
                  DataType="string">/tmp/games</AttributeValue>
               <AttributeValue
                  DataType="string">read, write</AttributeValue>
            </AttributeValue>
            <Apply FunctionId="j2se#function:permission-one-and-only">
              <ResourceAttributeDesignator
                 AttributeId="resource:resource-id"
                 DataType="j2se#class:java.security.Permission"
            </Apply>
          </Apply>
        </Apply>

      </Apply>

    </Condition>
  </Rule>

  <Rule RuleId="f234ab56c.2" Effect="Permit">
    <Condition FunctionId="and">

      <!-- grant signedBy "duke" -->

      <Apply FunctionId="j2se#function:certificate-is-in">
        <Apply FunctionId="j2se#function:getCertificateFromKeyStore">
          <AttributeValue DataType="string">duke</AttributeValue>
          <AttributeValue
             DataType="anyURI">file:/opt/keystores/.keystore</AttributeValue>
          <AttributeValue
             DataType="string">JKS</AttributeValue>
        </Apply>
        <SubjectAttributeDescriptor
           AttributeId="j2se#attribute:signerCertificate"
           SubjectCategory="codebase"
           DataType="j2se#class:java.security.Certificate"/>
        </SubjectAttributeDescriptor>
      </Apply>

      <!-- grant signedBy "sysadmin" -->

      <Apply FunctionId="j2se#function:certificate-is-in">
        <Apply FunctionId="j2se#function:getCertificateFromKeyStore">
          <AttributeValue DataType="string">sysadmin</AttributeValue>
          <AttributeValue
             DataType="anyURI">file:/opt/keystores/.keystore</AttributeValue>
          <AttributeValue
             DataType="string">JKS</AttributeValue>
        </Apply>
        <SubjectAttributeDescriptor
           AttributeId="j2se#attribute:signerCertificate"
           SubjectCategory="codebase"
           DataType="j2se#class:java.security.Certificate"/>
      </Apply>

      <!-- grant codeBase "http://my/classes" -->

      <Apply FunctionId="anyURI-is-in">
        <AttributeValue DataType="anyURI">http://my/classes</AttributeValue>
        <SubjectAttributeDescriptor
           AttributeId="subject:subject-id"
           SubjectCategory="codebase"
           DataType="anyURI"/>
      </Apply>

      <!-- grant principal "bob" -->

      <Apply FunctionId="x500Name-is-in">
        <Apply FunctionId="j2se#method:getSubjectDN">
          <Apply FunctionId="j2se#function:getCertificateFromKeyStore">
          <AttributeValue DataType="string">bob</AttributeValue>
          <AttributeValue
             DataType="anyURI">file:/opt/keystores/.keystore</AttributeValue>
          <AttributeValue
             DataType="string">JKS</AttributeValue>
        </Apply>
        <SubjectAttributeDescriptor
           AttributeId="subject:subject-id"
           SubjectCategory="access-subject"
           DataType="x500Name"/>
      </Apply>

      <!-- grant principal javax.security.auth.x500.X500Principal "cn=Alice" -->
      
      <Apply FunctionId="string-is-in">
        <AttributeValue
           DataType="string">cn=Alice</AttributeValue>
        <Apply FunctionId="map">
            <Apply FunctionId="j2se#method:getName">
              <SubjectAttributeDesignator
                 AttributeId="subject:subject-id"
                 DataType="j2se#class:javax.security.auth.x500.X500Principal"
            </Apply>
        </Apply>
      </Apply>

      <Apply FunctionId="or">

        <!-- "and" in case "permission ... signedBy" -->
        <Apply FunctionId="and">

          <!-- permission java.io.FilePermission
                    "/tmp/games", "read, write", -->

          <Apply
             FunctionId="j2se#method:implies">
            <AttributeValue
               DataType="j2se#class:java.io.FilePermission">
               <AttributeValue
                  DataType="string">/tmp/games</AttributeValue>
               <AttributeValue
                  DataType="string">read, write</AttributeValue>
            </AttributeValue>
            <Apply FunctionId="j2se#function:permission-one-and-only">
              <ResourceAttributeDesignator
                 AttributeId="resource:resource-id"
                 DataType="j2se#class:java.security.Permission"
            </Apply>
          </Apply>

          <!-- signedBy "FooSoft"; -->

          <Apply FunctionId="j2se#function:certificate-is-in">
            <Apply FunctionId="j2se#function:getCertificateFromKeyStore">
              <AttributeValue DataType="string">FooSoft</AttributeValue>
              <AttributeValue
                 DataType="anyURI">file:/opt/keystores/.keystore</AttributeValue>
              <AttributeValue
                 DataType="string">JKS</AttributeValue>
            </Apply>
            <ResourceAttributeDescriptor
               AttributeId="j2se#attribute:signerCertificate"
               DataType="j2se#class:java.security.Certificate"/>
          </Apply>

        </Apply>

        <!-- "and" in case "permission ... signedBy" -->
        <Apply FunctionId="and">

          <!-- permission java.security.SecurityPermission "Security.insertProvider.*" -->

          <Apply
             FunctionId="j2se#method:implies">
            <AttributeValue
               DataType="j2se#class:java.security.SecurityPermission">
               <AttributeValue
                  DataType="string">Security.insertProvider.*</AttributeValue>
               <AttributeValue
                  DataType="string"></AttributeValue>
            </AttributeValue>
            <Apply FunctionId="j2se#function:permission-one-and-only">
              <ResourceAttributeDesignator
                 AttributeId="resource:resource-id"
                 DataType="j2se#class:java.security.Permission"
            </Apply>
          </Apply>

        </Apply>

      </Apply>
    </Condition>
  </Rule>
</Policy>

--------------------------------------------------------------------------------

Appendix 3: Mappings for Standard J2SE Permission Subclasses
Certain Permission subclasses are provided in the standard J2SE platform distribution. For each of these, this appendix shows the semantics of the name and actions parameters, and what mappings, if any, should be performed for XACML. The word "ignored" below means that argument is supposed to be null or the empty string, or is ignored by the Permission subclass implementation.

java.security.AllPermission
Semantics:

name: ignored
actions: ignored
Mapped: no

javax.sound.sampled.AudioPermission
Semantics:

name: a permitted action, such as "play" or "record"
actions: ignored
Mapped: maybe

resource:resource-id: "audio"
action:action-id: value of "name"
javax.security.auth.AuthPermission
Semantics:

name: name of a security config parameter (doAsPrivileged, etc.)
actions: ignored
Mapped: no

java.awt.AWTPermission
Semantics:

name: symbolic action (accessClipboard, accessEventQueue, etc.)
actions: ignored
Mapped: no

ava.security.BasicPermission
Semantics:

name: name of permission
actions: ignored
Mapped: no

javax.security.auth.kerberos.DelegationPermission
Semantics:

name: specifies a pair of Kerberos service principals. The first is the subordinate service principal being entrusted to use the TGT. The second service principal designates the target service the subordinate service principal is to interact with on behalf of the initiating KerberosPrincipal. This latter service principal is specified to restrict the use of a proxiable ticket. the name of the subordinate and target principals
actions: ignored
Mapped: maybe

java.io.FilePermission
Semantics:

name: path (ends in "/*" (where "/" is the file separator character, File.separatorChar) indicates a directory and all the files contained in that directory. A pathname that ends with "/-" indicates a directory and (recursively) all files and subdirectories contained in that directory. The special pathname "<<ALL FILES>>" matches all files. A pathname consisting of a single "*" indicates all the files in the current directory, while a pathname consisting of a single "-" indicates all the files in the current directory and (recursively) all files and subdirectories contained in the current directory.
actions: comma separated list of actions ("read", "write", "execute", and "delete").
Mapped: yes

resource:resource-id = value of "name"
action:action-id = value of "actions". The PDP Interface Module parses the action list into individual actions, and submits one Request to the PDP.evaluate() API for each action. A value of "True" is returned as the return value of the Policy.implies API only if ALL such Requests evaluate to "Permit". Otherwise, a value of "False" is returned.
java.util.logging.LoggingPermission
Semantics:

name: must be "control"
actions: ignored
Mapped: no

java.net.NetPermission
Semantics:

name: permission name (setDefaultAuthenticator, requestPasswordAuthentication, specify StreamHandler)
actions: ignored
Mapped: maybe

java.security.Permission
Semantics: (abstract)

Mapped: no

javax.security.auth.PrivateCredentialPermission
Semantics:

name: the name specifying the Credential class and Principal Set.
actions: the actions specifying that the Credential can be read.
Mapped: maybe

java.util.PropertyPermission
Semantics:

name: the name of the system property (user.home, etc.)
actions: comma-separated list of the desired actions granted on the property. Possible actions are "read" and "write".
Mapped: no

java.lang.reflect.ReflectPermission
Semantics:

name: suppressAccessChecks
actions: ignored
Mapped: no

java.lang.RuntimePermission
Semantics:

name: createClassLoader, setSecurityManager, etc.
actions: ignored
Mapped: no

java.security.SecurityPermission
Semantics:

name: createAccessControlContext, setPolicy, setProperty.{key}, etc.
actions: ignored
Mapped: no

java.io.SerializablePermission
Semantics:

name: enableSubclassImplementation, enableSubstitution
actions: ignored
Mapped: no

javax.security.auth.kerberos.ServicePermission
Semantics:

name: Kerberos service principal name
actions: initiate, accept
Mapped: maybe

resource:resource-id = value of "name"
action:action-id = value of "actions". The PDP Interface Module parses the action list into individual actions, and submits one Request to the PDP.evaluate() API for each action. A value of "True" is returned as the return value of the Policy.implies API only if ALL such Requests evaluate to "Permit". Otherwise, a value of "False" is returned.
java.net.SocketPermission
Semantics:

name: host DNS name or IP address, with optional port range
actions: comma separated list "connect", "listen", "accept", "resolve", or any combination of those. "resolve" is automatically added when any of the other three are specified.
Mapped: yes

resource:resource-id = value of "name"
action:action-id = value of "actions". The PDP Interface Module parses the action list into individual actions, and submits one Request to the PDP.evaluate() API for each action. A value of "True" is returned as the return value of the Policy.implies API only if ALL such Requests evaluate to "Permit". Otherwise, a value of "False" is returned.
java.sql.SQLPermission
Semantics:

name: setLog
actions: ignored
Mapped: maybe

javax.net.ssl.SSLPermission
Semantics:

name: setHostnameVerifier, getSSLSessionContext
actions: ignored
Mapped: maybe

java.security.UnresolvedPermission
Semantics:

Used by Policy implementation to hold Permissions for which class does not yet exist when Policy is instantiated.
name: <String>
actions: <String>
Mapped: no

--------------------------------------------------------------------------------

Appendix 4: Notices
Sun, Sun Microsystems, Java[TM] 2 Platform, Standard Edition, J2SE[TM], Java Community Process(SM), and JCP(SM) are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

--------------------------------------------------------------------------------