OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xacml] Examples of J2SE Policy via XACML


**DISCLAIMER: these examples are exploratory in nature and are
known to have errors in interpretation of J2SE Java Policy API
semantics.  The examples are intended to explore possible issues
in using XACML with the J2SE Policy model.  These examples do not
represent a commitment on the part of Sun to implement any of
this.**

I have now worked out rough drafts of examples of handling J2SE
Policy using XACML.  There are three approaches:

 a) Translate the information passed in the J2SE Policy API into
    a SAML AuthorizationDecisionQuery.
 b) Specify a policy for use by a J2SE policy provider using an
    XACML extension schema that supports special predicates for
    J2SE Policy API information information.
 c) Specify a policy for use by a J2SE policy provider using
    special J2SE attribute names for J2SE Policy API information.

As the documents were produced (in order, a), b), c)), I received
comments from other people about semantics, etc.  These comments
were incorporated into subsequent documents, but I have not gone
back and corrected the earlier documents.

The documents are attached.  Approach b) has two documents:
examples, and schema.

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

**  This proposal is still under review by Sun's Java developers,
**  so it should be considered a very rough draft.  There is no
**  implied commitment on the part of Sun to implement any of this.

Title:   Translating Information from the Java Policy API into SAML
Author:  Anne Anderson
Version: 1.5, 02/04/18
Source:  /net/labeast/files2/east/info/projects/isrg/xacml/docs/SCCS/s.JPolicy_To_SAML.txt

The Java Policy mechanism could interoperate with XACML in one of
two ways:

 1) The information in the Java Policy API could be
    translated into SAML and passed to an XACML PDP,

 2) The XACML policy could be translated into objects that could
    be used by a Java Policy provider directly against the
    information in the API.

Since the XACML TC scope is to handle requests in SAML syntax, I
am going to describe the first approach.  I believe this
illustrates most of the issues that will arise in taking the
second approach as well, since it exposes the types of
information that need to be referenced from an XACML policy for
Java.  Later, I hope to describe the second approach.

1. Java Policy API Information

While there are several methods in the Java Policy API, the
critical one for interoperability with XACML is "implies":

  public boolean implies(ProtectionDomain domain,
                         Permission requestedPermission)

The next two sections describe the components of this API.  More
information about the Java Policy API and its component classes
is available in
http://lists.oasis-open.org/archives/xacml/200201/msg00082.html

Skip to Sections 2 and 3 if you are already familiar with the
Java Policy API.

1.1 Java ProtectionDomain

A "ProtectionDomain" is an object that can encapsulate five types
of information:

 - CodeSource:
    - URL: the URL from which the Classes associated with this
      ProtectionDomain were loaded.
    - Certificate[] containing certificates used to verify the
      signature on the Classes associated with this
      ProtectionDomain.
 - PermissionCollection: a collection of Permission objects,
    representing Permissions for which Classes associated with
    this ProtectionDomain have static rights.  These are granted
    by the ClassLoader.  The ClassLoader MAY get these
    Permissions from the Policy.getPermissions() API, but not
    necessarily.
 - ClassLoader: a reference to the ClassLoader used to load the
    Classes associated with this ProtectionDomain.
 - Principal[]: an array of names of the entity associated with
    the executing code (i.e. the Subject).  If the entity
    authenticated under multiple names, this array can contain an
    entry for each name.

There is a ProtectionDomain associated with each frame on a
thread stack.  Access is granted only if ALL ProtectionDomains
(or all down to a PD marked as Privileged) return TRUE from the
Policy.implies call OR from a
ProtectionDomain.PermissionCollection.implies call using the
statically granted permissions.  I am assuming that this
iteration can be performed by a front-end to the XACML PDP, so
each saml:AuthorizationDecisionQuery need express only one such
Policy.implies call.

1.2 Java Permission

A "Permission" is an object encapsulating a description of the
operation for which access is requested.  It is also used to
describe accesses that are permitted.

A Permission has a String "name", usually representing the the
requested target resource or task, and an optional String
"actions".

Permission objects are subclassed for particular types of
resources.  Some examples of such subclasses are:
  - FilePermission (access files)
  - SecurityPermission (set the Policy object, create an access
    control context, install provider objects, ...)
  - PrivateCredentialPermission (access private credentials
    associated with a Subject)
  - DelegationPermission (use Kerberos forwardable and
    proxiable tickets)
  - LoggingPermission (control logging configuration)
  - SQLPermission (set the logging stream for SQL)
  - SSLPermission (access or modify the SSL session information)
  - AudioPermission (access and control audio devices)
  - AuthPermission (run as "privileged" code, get the Subject
    associated with the current thread, modify set of Principal
    names associated with a Subject, ...)
  - SocketPermission (access sockets),
  - PropertyPermission (read or write system properties)
  - AWTPermission (control and access graphical display, such as
    accessing the event queue, accessing the clipboard, reading
    pixels, ...),
  - RuntimePermission (create a ClassLoader, set the
    SecurityManager, exit from the JVM, ...)

The important Permission method is "implies":

  public boolean implies(Permission otherPermission)

This method returns TRUE only if the "otherPermission" is a
subset, or is "covered by", this Permission.  What it means to
"imply" another Permission is completely under the control of the
specific Permission subclass.  It can make use of the Permission
information in any way it is programmed to do.  Specifically,
there is no requirement that either "name" or "actions" be of a
particular form.  "actions" can only be parsed by the Permission
subclass that handles them.

A wrinkle is that a Permissions that are granted can span more
than one Permission object.  For example, one FilePermission can
grant "read" access, while another FilePermission can grant
"write" access.  If the user requests "read, write" access, then
both FilePermissions must be logically "merged" to determine that
this access is allowed.  In the case of FilePermission, the
separate actions are comma-separated strings, but this is not the
case in general.  One Permission could grant part of a complex
access action, and another Permission could grant an overlapping
part of a complex access action.  Only the Permission subclass
itself could tell if the two actions together "match" a request
to perform the entire complex action.

Normally, a Permission is only compared to other Permissions that
are of the same subclass.  But there is a mechanism for a
Permission to associate itself with Permissions of another
sub-class.

To handle both the above cases, each Permission object implements
a "newPermissionCollection" method.  This returns null unless one
of the two cases above applies.  If it does not return null, the
method returns an empty instance of the PermissionCollection with
which instantiations of this Permission subclass must be merged.

If all Permission objects are stored in their corresponding
PermissionCollection, then
"PermissionCollection.implies(requestedPermission)" will handle
any necessary merging of targets and actions to produce the
definitive result.

2. SAML Translation Issues

The following is based on SAML draft-sstc-core-29.  The Version
29 AuthorizationDecisionQuery has a single Subject element with
an anyURI-type attribute of Resource.  It consists of:
 - a single NameIdentifier String-type element with optional
   NameQualifier and Format attributes,
 - 0 or more Action anyURI-type elements with a Namespace attribute.

2.1 Subject

SAML says the <Subject> element specifies the principal that is
the subject of the statement...  A <Subject> element SHOULD NOT
identify more than one principal.

The Java Policy API, however, can present multiple principals of
three types:
  - The principal associated with the execution of a thread stack
    stack that makes an access request.  This is often the "user"
    who is executing the application thread.  This principal may
    have multiple names if the principal authenticated under more
    than one name.  Java uses the Principal class such that
    various attributes of the "user" are expressed as Principal
    objects of specific subclasses.
  - The principals who signed the code that is executing.  These
    are represented by their public key certificates in the Java
    Policy API.  Each public key certificate may contain multiple
    names for the subject principal: the Subject Distinguished
    Name and the Subject Alternative Name Extensions.
  - The principal representing the location from which the code
    was loaded.  This is expressed as a single URI in the Java
    Policy API.

Proposal:

1. Extend <saml:Subject> to allow multiple <saml:NameIdentifier>
   elements.  The NameQualifier attribute can be used with each
   <saml:NameIdentifier> to distinguish the Java Principal
   sub-class and/or type (DN, OID, IP address, RFC822Name, etc.)

   This will allow a single Subject to express multiple names for
   the same principal.

2. Extend <saml:AuthorizationDecisionQuery> to allow multiple
   <saml:Subject> elements.  Extend <saml:Subject> to have a
   NameType attribute by which Executing Principal,
   CodeSource Signer, and CodeSource URL subjects may be
   distinguished, and a NameSpace attribute by which these
   special J2SE names can be identified.

An alternative for dealing with CodeSource URL would be to extend
the <saml:AuthorizationDecisionQuery> to include zero or more
<saml:Attribute>s.  This would not work so well for the other
principal types because they can each have multiple names that
need to be kept in association.

2.5 Requested Permission

The requested Permission encapsulates not only the Resource and
the Actions, but also the matching algorithm for comparing the
attribute values of this Permission to the attribute values that
may be expressed in the XACML policy.

A target Resource and Actions can be extracted from the Requested
Permission object in the Java Policy API, but we then lose the
information about the Permission subclass, which is essential for
understanding what the Resource and Actions mean and how they
match.

Once we agree that we need more than one <saml:Subject> in a
<saml:AuthorizationDecisionQuery>, it seems that Resource should
not be an XML attribute of the <saml:Subject>, and Action should
not be an element of the <saml:Subject>.  Both should be in one
or more separate elements.

To provide this information, I propose use of a new
<saml:Resource> element with two attributes: Namespace and
ResourceType.  The Resource type has two sub-elements:
ResourceName and ResourceAction.  The entire string returned from
requestedPermission.getActions() is placed into a single
"ResourceAction" element, since there is no reliable way to parse
it into separate actions.

2.6 Static Permissions

The PermissionCollection in a ProtectionDomain must be evaluated
together with whatever policy specification is used by the Java
Policy implementation, since the general case requires that
Permissions be logically merged.  For example, the executing user
may be requesting to "read" and "write" a given file, but "read"
access is granted in the static PermissionCollection and "write"
access is granted in the XACML Policy.  Evaluated separately,
each would return DENY to a request asking for "read and write"
access.

The static Permissions could be passed as a serialized object in a
SAML Attribute if the <saml:AuthorizationDecisionQuery> is
expanded to include <saml:Attribute>s.  I suggest the following:

Let "hexBytes" be the Base-64-encoded value of the serialized
PermissionCollection object.

     <saml:Attribute AttributeName="java.security.PermissionCollection"
                     AttributeNameSpace="j2se">
        <saml:AttributeValue>
           "hexBytes"
        </AttributeValue>
     </Attribute>

2.7 ClassLoader

The ClassLoader specified in the Java Policy API could be
expressed in a saml:Attribute if the
saml:AuthorizationDecisionQuery is expanded to include
<Attribute>s.

2.8 Full Query Example

Example:

The following AuthorizationDecisionQuery represents a Java Policy
API invocation where:
- The user Subject associated with the executing stack
  authenticated using an X500 Distinguished Name
  via a smart card login module.
- The code pointer in the stack frame is within a class loaded
  from "file:/netjavaxjdk1.4/classes".
- The class code was signed by two certificates, one of which had
  an X500 Distinguished Name, and the other of which had an
  RFC822 name and a CertificatePolicyExtension value.
- Read and write access is requested to the directory
  /home/aha/personal/.
- Some set of static Permissions was passed to the Java
  Policy.implies API.

  <saml:AuthorizationDecisionQuery>
     <saml:Subject Namespace="j2se" SubjectType="ExecutingPrincipal">
       <saml:NameIdentifier NameQualifier="javax.security.auth.X500Principal">
           "cn=Anne, ou=SunLabs, o=sun, c=us"
       </NameIdentifier>
       <saml:NameIdentifier NameQualifier="com.sun.labs.LoginTypePrincipal">
           "SCLoginModule"
       </NameIdentifier>
     </Subject>
     <saml:Subject Namespace="j2se" SubjectType="CodeSigner">
        <saml:NameIdentifier NameQualifier="javax.security.auth.X500Principal">
            "ou=JavaSoft, o=Sun, c=us"
        </NameIdentifier>
     </Subject
     <saml:Subject Namespace="j2se" SubjectType="CodeSigner">
        <saml:NameIdentifier NameQualifier="javax.security.auth.X500Principal">
            "RFC822:sunlabs@East.sun.com"
        </NameIdentifier>
        <saml:NameIdentifier NameQualifier="sun.security.x509.CertificatePolicyExtension">
            "0.2.4.12.5.126"
        </NameIdentifier>
     </Subject
     <saml:Attribute AttributeName="CodeSourceURL"
                     AttributeNameSpace="j2se">
        <saml:AttributeValue>
           "file:/net/javax/jdk1.4/classes"
        </AttributeValue>
     </Attribute>
     <saml:Attribute AttributeName="ClassLoader"
                     AttributeNameSpace="j2se">
        <saml:AttributeValue>
           "com.sun.east.sunlabs.XClassLoader"
        </AttributeValue>
     </Attribute>
     <saml:Attribute AttributeName="java.security.PermissionCollection"
                     AttributeNameSpace="j2se">
        <saml:AttributeValue>
           "hexBytes"
        </AttributeValue>
     </Attribute>
     <saml:Resource Namespace="j2se"
                    ResourceType="java.io.FilePermission">
        <saml:ResourceName>
           "/home/aha/personal/*"
        </ResourceName>
        <saml:ResourceAction>
           "read, write"
        </ResourceAction>
     </Resource>
  </AuthorizationDecisionQuery>

3. XACML Policy Evaluation Issues

Assume we have a <saml:AuthorizationDecisionQuery> such as
above.  What are the types of issues that will come up in
expressing policy against this type of query?

3.1 Multiple signing certificates

Rules may require that a given CodeSource be signed by multiple
specific principals, perhaps using certificates containing
specific field or extension values.  The CodeSource may actually
be signed by many principals, of which these need to be a
subset.

This is a place where using a subset operation and being able to
refer to an XPATH node set in the query from the XACML rule may
be useful.  Something like:

  <isSubsetOf>
    <valueRef>
      saml:Subject[@Namespace="j2se" @SubjectType="CodeSigner"]/
      NameIdentifier[@NameQualifier="javax.security.auth.X500Principal"]/
    </valueRef>
    <value>
      "ou=javasoft, o=sun, c=us"
    </value>
  </isSubsetOf>

3.2 Multiple Executing Principal Names

The policy may require that the executing principal have
authenticated under more than one name, or with specific
credentials.  The request may indicate that the principal has
actually authenticated under even more names.  The set of such
names in the request, however, must be a subset of the names
specified in the policy.

This is another place where the subset operator with an XPATH
node set would be useful.

3.3 rule Combiner

Handling the "overlapping Permission" problem in Java requires
some special processing.

First, I propose to allow a <rule> that is in a XACML policy used
for Java to return not only a list of missing attribute
references, but also the required values of those missing
attribute references.

Second, I propose a special <ruleCombiner> algorithm for use with
Java Policies that does the following:

 - constructs a Java Permission object from the information in the
   Resource Attribute of the the
   <saml:AuthorizationDecisionQuery>.
 - instantiates the java.security.PermissionCollection Attribute
   as the "overall" Java PermissionCollection.  If there is no
   such Attribute, then construct an empty "overall"
   PermissionCollection [This attribute could then be removed
   from the <saml:AuthorizationDecisionQuery>.]
 - evaluates each <rule> using all information from the
   <saml:AuthorizationDecisionQuery>.  If the <rule> returns
   PERMIT, then the <ruleCombiner> returns PERMIT.
 - re-evaluates the <rule>, omitting the input <Resource>
   element.  If the <rule> returns ERROR with "insufficient
   information", and the only missing information are references
   to the <Resource> element, then

   - for every such reference in the <rule>, construct a new
     Permission object using the required
     <saml:Resource[ResourceType]> as the Permission class, the
     required <saml:Resource/ResourceName> as the Permission
     "name" value, and the required
     <saml:Resource/ResourceAction> as the Permission "actions"
     value.

     Call the "p.getPermissionCollection()" on this new
     Permission object.  If it returns null, add the new
     Permission to the default PermissionCollection.  Otherwise,
     add the new Permission to the specified PermissionCollection
     object and then add the object to the "overall"
     PermissionCollection.

     [The ruleCombiner MAY invoke
      overallPermissionCollection.implies(permissionFromResource)
      after each addition.  If this invocation returns TRUE, then
      the <ruleCombiner> should return PERMIT, and the PDP should
      return PERMIT.]

   - After all <rule>s have been processed, invoke
     "overallPermissionCollection.implies(permissionFromResource)".
     If this returns TRUE, then the <ruleCombiner> returns
     PERMIT.  Otherwise, the <ruleCombiner> returns DENY.
Title:   JavaExtensions.txt
Author:  Anne Anderson
Version: 1.1, 02/04/17
Source:  /net/labeast/files2/east/info/projects/isrg/xacml/docs/SCCS/s.JavaExtensions.txt

Examples of use of the JavaExtensions.xsd extension schema to
specify rules and policies in XACML.  Base examples taken from 
http://webwork.eng.sun.com/j2se/1.4/docs/guide/security/PolicyFiles.html

GENERAL RULE
for translating PolicyFile to JavaExtensions.xsd:

-enclose list of "grant" entries in <or></or>, unless there is
 only one "grant" entry in a <xacml:rule>.  "grant" entries may
 be split up among multiple <xacml:rule>s as long as each "grant"
 entry is wholly contained in a single <xacml:rule>.

-elements of each "grant" entry are enclosed in <and></and>,
 unless the only elements are "permission" entries.

-All "permission" entries for a single "grant" entry are
 enclosed in <or></or>, unless there is only one "permission"
 entry in the "grant".  These "permission" entries must follow
 any other elements of the "grant" entry.

-"permission" entries with a "signedBy" clause are enclosed in
 <and></and>.

-"grant" entry elements are translated via <j2se:> elements in
 ways that should be clear from the examples below.

-A J2SE <rule> always has effect="Permit".

-A J2SE <policyStatement> always uses a ruleCombiningAlgId that
 implements J2SE Policy semantics.  These semantics are:

  1)  <rule>s are evaluated in any order; expressions within
      <rule>s are evaluated in order as specified.

  2)  Return "Permit" if any <rule> returns "true".

  3)  If no <rule> returns "Permit", return
      globalPermissionCollection.implies(requestedPermission)
      where the globalPermissionCollection is seeded from the
      PermissionCollection in the Java Policy API, and each
      <j2se:PermissionImplies> evaluation adds the constructed
      policyPermission to the globalPermissionCollection.

      A "signed" Permission entry is added to the
      globalPermissionCollection only if the
      <j2se:PermissionSignerCertificateMatch> entire <and></and>
      clause enclosing the signed Permission entry is "true".

EXAMPLES

1. Rule 1: combining multiple grant entries into one rule

<?xml version-"1.0" encoding-"UTF-8"?>
<rule ruleId-"//research.sun.com/people/anderson/rules/rule1"
      effect="Permit"
  xmlns=j2se-"http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd";
  xmlns=xacml-"http://www.oasis-open.org/committees/xacml/docs/draft-xacml-schema-policy-0.13b.xsd";
  xsi:schemaLocation-"http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd";>
  <description>XACML rule for the following PolicyFile grant statements:

       // 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";
       };

  </description>
  <condition>
    <or>
      <and>
        <j2se:SignerCertificateMatch>
           "Duke"
        </j2se:SignerCertificateMatch>
        <j2se:PermissionImplies class="java.io.FilePermission">
          <name>"/tmp/*"</name>
          <actions>"read,write"</actions>
        </j2se:PermissionImplies>
      </and>
      <j2se:PermissionImplies class="java.util.PropertyPermission">
        <name>"java.vendor"</name>
        <actions>"read"</actions>
      </j2se:PermissionImplies>
    </or>
  </condition>
</rule>  

2. Rule 2: Multiple permissions in a grant statement

<?xml version-"1.0" encoding-"UTF-8"?>
<rule ruleId-"//research.sun.com/people/anderson/rules/rule2"
      effect="Permit"
  xmlns=j2se-"http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd";
  xmlns=xacml-"http://www.oasis-open.org/committees/xacml/docs/draft-xacml-schema-policy-0.13b.xsd";
  xsi:schemaLocation-"http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd";>
  <description>XACML rule for the following PolicyFile grant statement:

  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.*";
       };
  </description>
  <condition>
    <and>
      <j2se:SignerCertificateMatch>
         "sysadmin"
      </j2se:SignerCertificateMatch>
      <j2se:CodeSourceURLMatch>
         "file:/home/sysadmin/*""
      </j2se:CodeSourceURLMatch>
      <or>
        <j2se:PermissionImplies class="java.security.SecurityPermission">
          <name>"Security.insertProvider.*"</name>
        </j2se:PermissionImplies>
        <j2se:PermissionImplies class="java.security.SecurityPermission">
          <name>"Security.removeProvider.*"</name>
        </j2se:PermissionImplies>
        <j2se:PermissionImplies class="java.security.SecurityPermission">
          <name>"Security.setProperty.*"</name>
        </j2se:PermissionImplies>
      </or>
    </and>
  </condition>
</rule>  

3. Rule 3: Permissions only in a grant statement

<?xml version-"1.0" encoding-"UTF-8"?>
<rule ruleId-"//research.sun.com/people/anderson/rules/rule3"
      effect="Permit"
  xmlns=j2se-"http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd";
  xmlns=xacml-"http://www.oasis-open.org/committees/xacml/docs/draft-xacml-schema-policy-0.13b.xsd";
  xsi:schemaLocation-"http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd";>
  <description>XACML rule for the following PolicyFile grant statement:

  grant {
           permission java.security.SecurityPermission "Security.insertProvider.*";
           permission java.security.SecurityPermission "Security.removeProvider.*";
       };
  </description>
  <condition>
    <or>
      <j2se:PermissionImplies class="java.security.SecurityPermission">
        <name>"Security.insertProvider.*"</name>
      </j2se:PermissionImplies>
      <j2se:PermissionImplies class="java.security.SecurityPermission">
        <name>"Security.removeProvider.*"</name>
      </j2se:PermissionImplies>
    </or>
  </condition>
</rule>  

4. Rule 4: Principal-based rule

<?xml version-"1.0" encoding-"UTF-8"?>
<rule ruleId-"//research.sun.com/people/anderson/rules/rule4"
      effect="Permit"
  xmlns=j2se-"http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd";
  xmlns=xacml-"http://www.oasis-open.org/committees/xacml/docs/draft-xacml-schema-policy-0.13b.xsd";
  xsi:schemaLocation-"http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd";>
  <description>XACML rule for the following PolicyFile grant statement:

       grant codebase "http://www.games.com";,
             signedBy "Duke",
             principal javax.security.auth.x500.X500Principal "cn=Alice" {
           permission java.io.FilePermission "/tmp/games", "read, write";
       };
  </description>
  <condition>
    <and>
      <j2se:SignerCertificateMatch>
         "Duke"
      </j2se:SignerCertificateMatch>
      <j2se:CodeSourceURLMatch>
         "http://www.games.com"";
      </j2se:CodeSourceURLMatch>
      <j2se:PrincipalMatch class="javax.security.auth.x500.X500Principal">
         "cn=Alice"
      </j2se:PrincipalMatch>
      <j2se:PermissionImplies class="java.io.FilePermission">
        <name>"/tmp/games"</name>
        <actions>"read, write"</actions>
      </j2se:PermissionImplies>
    </and>
  </condition>
</rule>  

5. Rule 5: Signed permission

<?xml version-"1.0" encoding-"UTF-8"?>
<rule ruleId-"//research.sun.com/people/anderson/rules/rule5"
      effect="Permit"
  xmlns=j2se-"http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd";
  xmlns=xacml-"http://www.oasis-open.org/committees/xacml/docs/draft-xacml-schema-policy-0.13b.xsd";
  xsi:schemaLocation-"http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd";>
  <description>XACML rule for the following PolicyFile grant statement:

  grant {
                    permission Foo "foobar", signedBy "FooSoft";
                }
  </description>
  <condition>
    <and>
      <j2se:PermissionImplies class="Foo">
          <name>"foobar"</name>
      </j2se:PermissionImplies>
      <j2se:PermissionSignerCertificateMatch>
          "FooSoft"
      <j2se:PermissionSignerCertificateMatch>
    </and>
  </condition>
</rule>  

6. Policy 1: Combine all previous rules into one policy

<?xml version-"1.0" encoding-"UTF-8"?>
<saml:Assertion MajorVersion="0" MinorVersion="28"
 AssertionId="http://research.sun.com/people/anderson/policies/policy1";
 Issuer="Anne Anderson"
 IssueInstant="2002-04-17T14:58:24-5:00"

 <policyStatement
   policyId="http://research.sun.com/people/anderson/policies/policy1";
   ruleCombiningAlgId="http://research.sun.com/people/anderson/combiners/javaCombiner1";
  xmlns=j2se-"http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd";
  xmlns=xacml-"http://www.oasis-open.org/committees/xacml/docs/draft-xacml-schema-policy-0.13b.xsd";
  xsi:schemaLocation-"http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd http://research.sun.com/people/anderson/schemas/JavaExtensions.xsd";>

    <target>
      <subjects/>
      <resources/>
      <actions/>
    </target>
    <ruleSet>
      <ruleDesignator>
        <ruleId>"//research.sun.com/people/anderson/rules/rule1"</ruleId>
      </ruleDesignator>
      <ruleDesignator>
        <ruleId>"//research.sun.com/people/anderson/rules/rule2"</ruleId>
      </ruleDesignator>
      <ruleDesignator>
        <ruleId>"//research.sun.com/people/anderson/rules/rule3"</ruleId>
      </ruleDesignator>
      <ruleDesignator>
        <ruleId>"//research.sun.com/people/anderson/rules/rule4"</ruleId>
      </ruleDesignator>
      <ruleDesignator>
        <ruleId>"//research.sun.com/people/anderson/rules/rule5"</ruleId>
      </ruleDesignator>
    </ruleSet>
  </policyStatement>
</saml:Assertion>
<?xml version="1.0" encoding="UTF-8"?>
<!-- Title:   JavaExtensions.txt
     Author:  Anne Anderson
     Version: 1.2, 02/04/17
     Source:  /net/labeast/files2/east/info/projects/isrg/xacml/docs/SCCS/s.JavaExtensions.xsd
  -->
<!-- experimental extension to XACML schema v0.13b.xsd to define
     operators for J2SE Policy API.  This extension is purely
     experimental as a "proof-of-concept".  There is no implied
     commitment on the part of Sun to implement any of this.
-->
<xs:schema
 targetNamespace="http://research.sun.com/people/anderson/schemas/j2sePolicy.xsd";
 xmlns:xacml="http://www.oasis-open.org/committees/xacml/docs/draft-xacml-schema-policy-13.xsd";
 xmlns:j2se="http://research.sun.com/people/anderson/schemas/j2sePolicy.xsd";
 elementDefaultForm="qualified"
 attributeFromDefault="unqualified">

    <!-- The primary Java Policy API is:

          public boolean implies(ProtectionDomain domain,
                         Permission requestedPermission)

         This XACML schema extension supports operations on
         the information passed in that API.
     -->

    <!-- TYPES -->

    <!-- compare an implicit reference to Java API information
         with the specified string.  If a "class" attribute is
         specified, then uses the specified string to create an
         instance of the specified "class" and invokes the
         class.equals method.  Otherwise, does a String
         comparison.
      -->
    <xs:complexType name="StringCompareType">
        <xs:complexContent>
            <xs:extension base="xs:string"/>
            <xs:attribute name="class" type="xs:string" use="optional"/>
        </xs:complexContent>
    </xs:complexType>

    <!-- compare an implicit reference to Java API information
         with the specified string.  The "class" and "method"
         attributes specify the object class to be compared and a
         specific method used to obtain information from the
         implicitly referenced object.  If the method returns a
         List or Collection, then the comparison is performed on
         each element in the List or Collection.  If the value
         being compared is not a String, it is converted to a
         String.  If the implicitly referenced object is not an
         instance of "class", or if the specified "method" is not
         defined for the object, then the operation returns
         "false".
      -->
    <xs:complexType name="MethodStringCompareType">
        <xs:complexContent>
            <xs:extension base="xs:string"/>
            <xs:attribute name="class" type="xs:string" use="required"/>
            <xs:attribute name="method" type="xs:string" use="required"/>
        </xs:complexContent>
    </xs:complexType>

    <!-- specify values for constructing a Permission object
      -->
    <xs:complexType name="PermissionType">
        <xs:complexContent>
            <xs:sequence>
                <xs:element name="name" type="xs:string" minOccurs="0"/>
                <xs:element name="actions" type="xs:string" minOccurs="0"/>
            </xs:sequence>
        </xs:complexContent>
        <xs:attribute name="class" type="xs:string" use="required"/>
    </xs:complexType>

    <!-- specify a Keystore -->
    <xs:complexType name="KeystoreType">
        <xs:complexContent>
            <xs:sequence>
                <xs:element name="url" type="xs:URI" minOccurs="1" maxOccurs="1"/>
                <xs:element name="type" type="xs:string" minOccurs="0"/>
            </xs:sequence>
        </xs:complexContent>
    </xs:complexType>


    <!-- COMPARISON OPERATORS -->

    <!-- Uses the specified string to create a java.net.URL
         object: policyURL.  Returns the result of
         domain.getCodeSource().getLocation().equals(policyURL).
      -->
    <xs:element name="CodeSourceURLMatch"
                type="j2se:StringCompareType"
                substitutionGroup="xacml:predicate"/>

    <!-- returns "true" if the specified certificate from the
         keystore with alias "string" matches at least one of the
         certificates returned from
         domain.getCodeSource().getCertificates().
      -->
    <xs:element name="SignerCertificateMatch"
                type="j2se:StringCompareType"
                substitutionGroup="xacml:predicate"/>

    <!-- returns "true" if the specified string matches the
         value returned by the specified method
         on the object returned by domain.getClassLoader().
      -->
    <xs:element name="ClassLoaderMatch"
                type="j2se:MethodStringCompareType"
                substitutionGroup="xacml:predicate"/>

    <!-- uses the specified string to create a Principal object
         of the specified "class": policyPrincipal.  Returns
         "true" if for at least one p in domain.getPrincipals(),
         p.equals(policyPrincipal).
      -->
    <xs:element name="PrincipalMatch"
                type="j2se:StringCompareType"
                substitutionGroup="xacml:predicate"/>

    <!-- returns "true" if a Permission object constructed
         from the specified values "implies" the
         requestedPermission.
      -->
    <xs:element name="PermissionImplies"
                type="j2se:PermissionType"
                substitutionGroup="xacml:predicate"/>

    <!-- returns "true" if the specified certificate from the
          keystore with alias "string" matches at least one of
          the certificates used to sign the
         requestedPermission's class.
      -->
    <xs:element name="PermissionSignerCertificateMatch"
                type="j2se:StringCompareType"
                substitutionGroup="xacml:predicate"/>

     <!-- returns true if the specified keystore database can
          be located and is the correct type.  Sets the keystore
          for reference by subsequent alias specifications.
       -->
    <xs:element name="Keystore"
                type="KeystoreType"
                substitutionGroup="xacml:predicate"/>
</xs:schema>
Title:   JavaAttributes.txt
Author:  Anne Anderson
Version: 1.4, 02/04/18
Source:  /net/labeast/files2/east/info/projects/isrg/xacml/docs/SCCS/s.JavaAttributes.txt

This is the third of three proposals for using XACML with J2SE
policies.

This proposal uses distinguished J2SE attributes to specify rules
XACML.  It requires use of a PDP that is "J2SE-aware" and
recognizes these distinguished attributes and their special
predicate semantics.  It also requires use of a J2SE
ruleCombiningAlgIg as specified below.

GENERAL RULE
============

For translating a PolicyFile to XACML using distinguished
attributes:

-if a keystore is specified, use the keystore predicate shown
 below, and list it first in each <ruleSet> derived from the
 PolicyFile.

-enclose the translated list of "grant" entries in <or></or>,
 unless there is only one "grant" entry in a <xacml:rule>.
 Translated "grant" entries may be split up among multiple
 <xacml:rule>s as long as each "grant" entry is wholly contained
 in a single <xacml:rule>.

-translated elements of each "grant" entry are enclosed in
 <and></and>, unless the only elements are "permission" entries.

-All translated "permission" entries for a single "grant" entry
 are enclosed in <or></or>, unless there is only one "permission"
 entry in the "grant".  These "permission" entries must follow
 any other elements of the "grant" entry.

-Translated "permission" entries with a "signedBy" clause are
 enclosed in <and></and> with the translated "signedBy" clause
 first.

-the <xacml:policyStatement> must use a J2SERuleCombiningAlgId
 that enforces the following:
 a) Creates a globalPermissionCollection object seeded from any
    PermissionCollection (static permissions) passed in the Java
    Policy API invocation.
 b) All predicates are evaluated in order.
 c) If any element in an <and> predicate returns "false", then no
    further elements in the <and> predicate are evaluated.
 d) Recognize the special j2se Attribute and AttributeDesignator
    names.
 e) Return "Permit" whenever a <rule> returns "Permit".
 f) Whenever a j2se:permission attribute designator is evaluated,
    add the associated "policyPermission" object to the
    globalPermissionCollection.
 f) If no <rule> returns "Permit", then return
    if (globalPermissionCollection.implies(requestedPermission))
    {
        return true;
    } else {
        return false;
    }

-"grant" statement elements are translated via <j2se:> elements
 in ways that should be clear from the examples below.


GRANT ELEMENT TRANSLATIONS TO XACML
===================================

    <!-- The primary Java Policy API is:

          public boolean implies(ProtectionDomain domain,
                         Permission requestedPermission)
     -->

1. Permission entry

  <equals>
    <saml:AttributeDesignator AttributeName-"permission"
                              AttributeNamespace-"j2se"/>
    <saml:Attribute AttributeName-"java.io.FilePermission"
                    AttributeNamespace-"j2se">
        <saml:AttributeValue>"/tmp/*"</saml:AttributeValue>
        <saml:AttributeValue>"read,write"</saml:AttributeValue>
    </saml:Attribute>
  </equals>

  <equals> in the case where the AttributeDesignator is
  j2se:permission does the following:

    a) Create an object - policyPermission - from the following
       <saml:Attribute> using the AttributeName as the Java class
       and the AttributeValue(s) as the parameters to the
       constructor.
    b) return result of
       policyPermission.implies(requestedPermission)
    c) add policyPermission to globalPermissionCollection.

  See 5. for special rules where Permission "signBy" clause is
  present.

2. CodeBase Field

  <equals>
    <saml:AttributeDesignator AttributeName-"codeBase"
                              AttributeNamespace-"j2se"/>
    <saml:Attribute AttributeName-"java.net.URL"
                    AttributeNamespace-"j2se">
        <saml:AttributeValue>"http://research.sun.com/*";</saml:AttributeValue>
    </saml:Attribute>
  </equals>

  <equals> in the case where the AttributeDesignator is
  j2se:codeBase does the following:
    a) Create an object - policyURL - from the following
       <saml:Attribute> using the AttributeName as the Java class
       and the AttributeValue(s) as the parameters to the
       constructor.
    b) return result of
       policyURL.implies(domain.getCodeSource().getLocation())

3. SignedBy Field

  <equals>
    <saml:AttributeDesignator AttributeName-"signedBy"
                              AttributeNamespace-"j2se"/>
    <saml:Attribute AttributeName-"certificateAlias"
                    AttributeNamespace-"j2se">
        <saml:AttributeValue>"Duke"</saml:AttributeValue>
    </saml:Attribute>
  </equals>

  <equals> in the case where the AttributeDesignator is
  j2se:signedBy does the following:
    a) Retrieve a certificate - policyCertificate - using the following
       <saml:Attribute>.  If the AttributeName is
       "certificateAlias", then the certificate is fetched from the
       keystore using the AttributeValue as the alias.  [Other types
       of Attributes or AttributeDesignators may point to or
       specify a Der-encoded certificate using the AttributeName as
       the Java class and the AttributeValue(s) as the certificate
       value (or pointer).]
    b) for each certificate in domain.getCertificates() {
          if (policyCertificate.equals(certificate) {
             return true;
          }
       }
       return false;

4. Principal Field

  <equals>
    <saml:AttributeDesignator AttributeName-"principal"
                              AttributeNamespace-"j2se"/>
    <saml:Attribute AttributeName-"javax.security.auth.x500.X500Principal"
                    AttributeNamespace-"j2se">
        <saml:AttributeValue>"cn=Anne"</saml:AttributeValue>
    </saml:Attribute>
  </equals>

  <equals> in the case where the AttributeDesignator is
  j2se:principal does the following:
    a) If the AttributeName class has a constructor that takes a
       single string, then, the PDP MAY create an object -
       policyPrincipal - from the following 
       <saml:Attribute> using the AttributeName as the Java class
       and the AttributeValue(s) as the parameters to the
       constructor.
    b) If the PDP constructed a policyPrincipal in step a), then

    b1) for each principal in domain.getPrincipals {
         if (policyPrincipal.implies(principal)) {
            return true;
         }
       }
       return false;

    b2) otherwise:

       for each principal in domain.getPrincipals {
          if (AttributeValue.equals(principal.getName())) {
              return true;
          }
       }
       return false;

5. Permission SignedBy Field

  <equals>
    <saml:AttributeDesignator AttributeName-"permissionSignedBy"
                              AttributeNamespace-"j2se"/>
    <saml:Attribute AttributeName-"certificateAlias"
                    AttributeNamespace-"j2se">
        <saml:AttributeValue>"Duke"</saml:AttributeValue>
    </saml:Attribute>
  </equals>

  <equals> in the case where the AttributeDesignator is
  j2se:permissionSignedBy does the following:
    a) Fetch a certificate - policyCertificate - using the
       following <saml:Attribute> (as in 3).
    b) Let certificates be the collection of certificates used to
       sign the class of the requestedPermission.
    c) for certificate in certificates {
           if (policyCertificate.equals(certificate)) {
               return true;
           }
       }
       return false;

  All permissionSignedBy <equals> tests must be in an <and>
  predicate together with the <equals> test for the associated
  permission.  The permission <equals> test must be the last test
  in the <and> predicate.

6. ClassLoader

  We could define an attribute for the classLoader, but this is
  apparently not used (currently) in Java policies.

7. Keystore

  <present>
    <saml:Attribute AttributeName-"keystore"
                    AttributeNamespace-"j2se">
        <saml:AttributeValue>
            "<path to keystore>"
        </saml:AttributeValue>
        <saml:AttributeValue>
            "<keystore type>"
        </saml:AttributeValue>
    </saml:Attribute>
  </present>

  This attribute has one or two values, the first being the path to
  the keystore, and the second being the keystore type.

  When <present> is used with a j2se:keystore attribute, the
  predicate returns "true" if the specified keystore attribute can
  be accessed.  It also causes the specified keystore to be saved
  in the PDP context for use in resolving "certificateAlias"
  attributes.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC