xacml message

Subject: [xacml] J2SE use of XACML

From: Anne Anderson <Anne.Anderson@Sun.com>
To: XACML TC <xacml@lists.oasis-open.org>
Date: Wed, 10 Jul 2002 17:43:26 -0400 (EDT)

The attachment represents my action item to provide an example
for how J2SE would use XACML with the current schema.  It is not
yet brought up to schema 15, but should not be too far off.

There may be typos: I was trying to do my final edits over a very
slow dialup line.

This has been quickly reviewed by my own research team, but not
by any J2SE development engineers, so it is very much just my own
idea for now.

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

Title: Proposal: J2SE Use of XACML

Proposal: J2SE Use of XACML

This is a proposal for how J2SE could make use of XACML as its policy language. This proposal is in no way a commitment by Sun or any JCP group to implement any of this.

Implementation Model
Summary of Issues and Recommended Actions
Example Policy In English
Proposed XACML Policy Specification
Request Example 1: Non-J2SE-Specific Resource
Request Example 2: J2SE-Specific Resource
Rejected Implementation Models
References

A. Implementation Model

A "standard" XACML PDP will be the core of the J2SE Policy Provider, handling all resources and policies, both J2SE-specific and non-J2SE-specific. A "shim" in the J2SE Policy Provider will provide the interface between the J2SE Policy API and the XACML Request and Response. J2SE-specific resource protection is handled via published J2SE Extensions to XACML.

 _____________            __________           _________
| J2SE        |-Access-->| J2SE     | -J2SE-->| J2SE    |
| Application | Request  | Security |  Policy | Policy  |
|_____________|          | Manager  |  API    | Provider|
                         |__________|<-true/--|_________|
                                       false

J2SE Policy Provider internal structure:
 __________________            ____________________
| J2SE Policy      |--XACML-->| XACML | J2SE       |
| to XACML Request |  Request | PDP   | Extensions |
| Translator       |  Context |       | Support    |
|__________________|<-XACML---|_______|____________|
                      Response
                      Context

"J2SE Extensions Support" consists of one module designed to handle policy Function elements with FunctionName "j2se:implies".

This module accepts an Attribute with AttributeNamespace "j2se:Constructor" and an AttributeName corresponding to a class name. The value of the attribute is a sequence of values corresponding to argument values for a constructor for the class.

The module also accepts an AttributeSelector that points to a serialized Permission object.

The module functions by locating a constructor for the class that accepts arguments of the types specified in the AttributeValue. It then constructs an instance of the class object using the AttributeValues as arguments.

The module then de-serializes the serialized Permission passed in the Request, and passes the de-serialized Permission as an argument to the "implies" method of the constructed Permission.

The module returns the result of the "implies" invocation as the result of evaluating the Function.

B. Summary of Issues and Recommended Actions

Handling of java.security.Policy getPermissions methods.
RECOMMENDED ACTION: Return null. If an XACML Provider is used, getPermissions is not supported.
It would be possible to construct an XACML PDP that returned the equivalent of "getPermissions" as Advice. Providing this functionality, however, would not be simple, and would introduce the need to handle Issue 2 below.
getPermissions does not have a well-defined function currently, other than being available as an optimization technique for particular implementations. J2SE should probably move toward a simpler model in which all access control decisions are made through the Policy "implies" interface.
Handling of overlapping Permissions from the input ProtectionDomain and from the java.security.Policy implies method parameter.
RECOMMENDED ACTION: Ignore any Permissions in the ProtectionDomain. If an XACML Provider is used, overlapping Permissions are not supported.
The semantics of overlapping permissions is very complex in the existing J2SE architecture. It is unlikely that any general policy system will support or require such complex semantics. J2SE should probably move toward a simpler model for the future, in order to co-exist with other centralized access control mechanisms, such as XACML.

C. Example Policy In English

The following policy has two rules.

The first rule specifies that only a requester authenticated as "Bart.Simpson@Simpsons.COM" is allowed to read the directory "/home/bs" on host machine "saguaro.simpsons.com".

The second rule specifies that only a requester having a "role" attribute value of "System Administrator" is granted access for all Permissions implied by an instance of the com.simpsons.FooPermission class constructed using arguments "String duh+" and "String buh".

The policy will allow access if either rule returns "Permit".

D. Proposed XACML Policy Specification

<PolicyStatement
    PolicyId="com.simpsons:policies:Policy1"
    RuleCombiningAlgId="xacml:RuleCombiningAlgIds:PermitOverrides">
  <Description>"Simpsons Policy"</Description>
  <Target>
    <Subjects>"xacml:anySubject"</Subjects>
    <Resources>"xacml:anyResource"</Resources>
    <Actions>"xacml:anyAction"</Actions>
  </Target>
  <RuleSet>
    <Rule RuleId="com.simpsons:rules:Rule1"
          Effect="Permit">
      <Target>
        <Subjects>
            <RequiredAttributeMatch RequestValue=
                '/Request/Subject[@SubjectCategory
                ="urn:oasis:names:tc:xacml:identifiers:AccessSubject"]
                /SubjectId[@Format
                ="urn:oasis:names:tc:xacml:identifiers:RFC822Name"]'>
            <RequiredMatchingValue>
                "Bart.Simpson@Simpsons.COM"
            </RequiredMatchingValue>
        </Subjects>
        <Resources>
            <RequiredAttributeMatch RequestValue=
                '/Request/Resource/ResourceSpecifier
                [@Scope="descendants" and
                 @ResourceURI="file://saguaro.simpsons.com/home/bs"]'>
        </Resources>
        <Actions>"urn:oasis:names:tc:xacml:identifiers:Read"</Actions>
      </Target>
    </Rule>
    <Rule RuleId="com.simpsons:rules:Rule2"
        Effect="Permit">
      <Target>
        <Subjects>
            <RequiredAttributeMatch RequestValue=
            "/Request/Subject/SubjectAttribute/AttributeMetaData
            [@Name="role" and @Namespace="urn:com:simpsons:attributes"]
            /AttributeValue">
          <RequiredMatchingValue>
          "SystemAdministrator"
          </RequiredMatchingValue>
        </Subjects>
        <Resources>
            <RequiredAttributeMatch RequestValue=
            "/Request/Resource/ResourceSpecifier
            [@Format="j2se:SerializedObject" and
             @ResourceURI="j2se:com.simpsons.FooPermission"]/>
        </Resources>
        <Actions>"xacml:actions:implied</Actions>
      </Target>
      <Condition
          <Function
              FunctionName="j2se:implies">
            <Attribute AttributeName="com.simpsons.FooPermission"
                       AttributeNamespace="j2se:Constructor">
                <AttributeValue>
                    <xs:String>"duh+"</xs:String>
                    <xs:String>"buh"</xs:String>
                </AttributeValue>
            </Attribute>
            <AttributeSelector>
                /Request/Resource/ResourceSpecifier
                [@Format="j2se:SerializedObject" and
                 @ResourceURI="j2se:com.simpsons.FooPermission]
                /../ResourceContent/xs:base64Binary"/>
            </AttributeSelector>
      </Condition>
    </Rule>
  </RuleSet>
</PolicyStatement>

E. Request Example 1: Non-J2SE-Specific Resource

E.1 Request Description in English

Codesource "com.simpsons.applet.y" signed by "o=simpsons,c=us" and "o=y,c=us", that is part of a thread associated with a user authenticated as "cn=Bart Simpson, o=simpsons, c=us" and as "Bart.Simpson@simpsons.COM", requests read and write access to the directory subtree "/home/bs" on host "saguaro.simpsons.com".

E.2 Proposed XACML Request Specification

The access request as it comes in from the java.security.Policy "implies" API contains the following data:

ProtectionDomain
    CodeSource
        URL("http://www.simpsons.com/apps/com.simpsons.applet.y")
        Certificate[]
            [0]certificate with Subject "o=simpsons,c=us"
            [1]certificate with Subject "o=y,c=us"
    PermissionCollection "Gobbledegook"
    ClassLoader "Gobbledegook"
    Principal[]
        [0]X500Principal("cn=Bart Simpson,o=simpsons,c=us")
        [1]com.simpsons.EmailPrincipal("Bart.Simpson@simpsons.COM")
Permission
    FilePermission("//saguaro.simpsons.com/home/bs/-", "read,write")

The "J2SE Policy to XACML Request Translator" (JPXRT) notes that FilePermission is in its list of "non-J2SE Resources" and invokes its special FilePermission handler.

The FilePermission handler calls the FilePermission "getName" method, interprets the tail of the URI in order to determine that Scope should be "descendants", then returns "file://saguaro.simpsons.com/home/bs/" as what should go into the Resource element.

The FilePermission handler then calls the FilePermission "getActions" method and parses the resulting string into two comma-separated actions. It returns these as what should go into the Action element.

The JPXRT constructs two XACML Requests, one for each action. The JPXRT will return true as the result of the J2SE Policy API only if both XACML Requests receive an XACML Response of "Permit".

E.2.1 First request

<Request>
  <Subject
      SubjectCategory="urn:oasis:names:tc:xacml:identifiers:AccessSubject">
    <SubjectId
         Format="urn:oasis:names:tc:xacml:identifiers:X500DistinguishedName">
       "cn=Bart Simpson, o=simpsons, c=us"
    </SubjectId>
  </Subject>
  <Subject
      SubjectCategory="urn:oasis:names:tc:xacml:identifiers:AccessSubject">
    <SubjectId
         Format="urn:oasis:names:tc:xacml:identifiers:RFC822Name">
       "Bart.Simpson@simpsons.com"
    </SubjectId>
  </Subject>
  <Subject
      SubjectCategory="urn:j2se:names:xacml:identifiers:CodeSource">
    <SubjectId Format="URL">
        "http://www.simpsons.com/apps/com.simpsons.applet.y"
    </SubjectId>
    <SubjectAttribute>
        <AttributeMetaData Name="SignedBy"
            Namespace="urn:j2se:names:xacml:identifiers"/>
        <AttributeValue>
          "o=simpsons,c=us"
        </AttributeValue>
        <AttributeValue>
          "o=y,c=us"
        </AttributeValue>
    </SubjectAttribute>
  </Subject>
  <Resource>
    <ResourceSpecifier Scope="descendants"
        ResourceURI="file://saguaro.simpsons.com/home/bs"/>
  </Resource>
  <Action>
      "urn:oasis:names:tc:xacml:identifiers:Read"
  </Action>
</Request>

E.2.2 Second Request

The second request is identical, except that <Action> is

<Action>
  "urn:oasis:names:tc:xacml:identifiers:Write"
</Action>

E.3 Decision in English

The XACML PDP evaluates the first request against the policy target and determines that the policy applies to the request.

The PDP then evaluates the first request against the target of the first rule, and determines that the rule applies. Since there is no condition in the first rule, the rule has been satisfied and the rule returns the effect "Permit".

Since the RuleCombiningAlgId for the policy is "PermitOverrides", the policy can now return "Permit" as the result of evaluating the first request.

The XACML PDP evaluates the second request against the policy target, and again decides that the policy applies to the request.

The PDP then evaluates the second request against the target of the first rule. The rule does not apply, since the requested Action is now "Write", whiile the rule target specifies only "Read". The first rule returns "Inapplicable".

The PDP then evaluates the second request against the target of the second rule. It attempts to retrieve an attribute for the subject with attribute name "role" and attribute value "SystemAdministrator". While such an attribute is not in the Request, it triggers a call to an Attribute Authority, which returns such an Attribute.

The PDP now tries to evaluate the Resources section of the second rule target. This fails. The second rule also returns "Inapplicable".

According to the policy RuleCombiningAlgId, the result of evaluating the second request, since neither rule returned Permit, is "Deny".

The JPXRT returns "false" from the Policy API "implies" method, since both requests would need to evaluate to "Permit" for the request to be allowed.

E.4 Proposed XACML Response Specification

The response from the first request is:

<Response>
  <Decision>
    <Effect>Permit</Effect>
  </Decision>
</Response>

The response from the second request is:

<Response>
  <Decision>
    <Effect>Deny</Effect>
  </Decision>
</Response>

The response from the Policy API "implies" method is "false".

F. Request Example 2: J2SE-Specific Resource

F.1 Request Description in English

Codesource "com.simpsons.applet.y" signed by "o=simpsons,c=us" and "o=y,c=us", that is part of a thread associated with a user authenticated as "cn=Bart Simpson, o=simpsons, c=us" and as "Bart.Simpson@simpsons.COM" requests access to a resource specified by an instance of class "com.simpsons.FooPermission".

F.2 Proposed XACML Request Specification

<Request>
  <Subject
      SubjectCategory="urn:oasis:names:tc:xacml:identifiers:AccessSubject">
    <SubjectId
         Format="urn:oasis:names:tc:xacml:identifiers:X500DistinguishedName">
       "cn=Bart Simpson, o=Simpsons, c=us"
    </SubjectId>
  </Subject>
  <Subject
      SubjectCategory="urn:oasis:names:tc:xacml:identifiers:AccessSubject">
    <SubjectId
         Format="urn:oasis:names:tc:xacml:identifiers:RFC822Name">
       "Bart.Simpson@Simpsons.com"
    </SubjectId>
  </Subject>
  <Subject
      SubjectCategory="urn:j2se:names:xacml:identifiers:CodeSource">
    <SubjectId Format="URL">
        "http://www.simpsons.com/apps/com.simpsons.applet.y"
    </SubjectId>
    <SubjectAttribute>
        <AttributeMetaData Name="SignedBy"
            Namespace="urn:j2se:names:xacml:identifiers"/>
        <AttributeValue>
          "o=simpsons,c=us"
        </AttributeValue>
        <AttributeValue>
          "o=y,c=us"
        </AttributeValue>
    </SubjectAttribute>
  </Subject>
  <Resource>
    <ResourceSpecifier Format="j2se:SerializedObject"
        Scope="immediate"
        ResourceURI="j2se:com.simpsons.FooPermission"/>
    <ResourceContent>
        <xs:base64Binary>
CCqGSIb3DQMHMBMGA1UdJQQMMAoGCCsGAQUFBwMDMB0GA1UdDgQWBBQR6BWe3NaAr3ZH2cJddxf
        </xs:Base64Binary>
  </Resource>
  <Action>
      "urn:oasis:names:tc:xacml:identifiers:Implied"
  </Action>
</Request>

F.3 Decision in English

The XACML PDP evaluates the request against the target of Rule 1 and determines that the rule does not apply.

The XACML PDP now evaluates the request against the target of Rule 2.

The XACML PDP attempts to reference a "role" attribute with value "System Administrator" in the Subjects portion of the Request. This initiates a call to an Attribute Authority, which retrieves such an attribute for Subject "cn=Bart Simpson, o=simpsons, c=us" and returns it. This satisfies the Subjects target of Rule2.

The XACML PDP attempts to reference a "FooPermission" resourceURI, finds it, and this satisfies the remainder of the Target for Rule 2.

The XACML PDP now attempts to evaluate the condition portion of Rule 2.

The XACML PDP recognizes FunctionName "j2se:implies" as a reference to a function provided by the J2SE Extensions Support module. The PDP passes the Function specification (probably parsed) to the J2SE module.

The J2SE module recognizes AttributeName "com.simpsons.FooPermission" as a Class, and namespace "j2se:Constructor" as an indicator that an instance of this class is to be constructed using the provided arguments. The module locates a constructor that takes two "String" arguments, and uses it to construct an object instance.

The J2SE module then de-serializes the AttributeSelector into another instance of com.simpsons.FooPermission.

The J2SE module then passes the deserialized FooPermission to the "implies" method of the constructed "FooPermission" and returns the result.

Assume the result of the FooPermission.implies is "false". Since Rule2 is a "Permit" rule, and since our RuleCombiningAlgId is "PermitOverrides", we return a value of "Deny", since there was no Permit returned from either of the two rules.

F.4 Proposed XACML Response Specification

<Response>
  <Decision>
    <Effect>Deny</Effect>
  </Decision>
</Response>

The Policy API "implies" method returns "false".

G. Rejected Implementation Models

G.1 Separate J2SE and XACML Resource Handlers

Have a J2SE Policy Provider that handles access to J2SE-specific resources. This J2SE Policy Provider invokes an XACML PDP to handle access to non-J2SE-specific resources.

PRO: XACML PDP requires no J2SE extensions.
NEUTRAL: requires J2SE Provider to identify non-J2SE-specific resources and translate them into an XACML Request Context. This task must be performed in either case.
CON: requires continuing to maintain separate J2SE Provider and its tools for creating policies.
CON: does not provide XML policies for J2SE-specific resources.
CON: requires J2SE Policy Provider to decide how to handle "merge" of response from XACML PDP and J2SE policy.
CON: does not provide ability to have distributed or centralized policies for J2SE-specific resources.

G.2 XACML Policy Syntax as Replacement for PolicyFile

Use only the XACML core policy schema, as a replacement for PolicyFile as input to a J2SE Policy Provider. Do not use XACML Request or Response.

PRO: fairly trivial to implement.
PRO: policy issuers could use mass-market XACML policy builder tools. Although without modification, such policies might include references into the implicit XACML Request that are not supported or appropriate.
PRO: requires no extensions to XACML. The Policy Provider can recognize J2SE-specific attribute references and handle them accordingly.
CON: XACML policy references to attributes would need to be translated into references to appropriate J2SE objects, either pointing to Policy API objects, or pointing to attribute objects obtained from other sources by the Policy Provider.
CON: resulting PDP can not be used as a standard XACML-compliant PDP.
CON: J2SE applications would have no way to use a standard XACML-compliant PDP.
CON: no way to include a J2SE-application in a broader policy domain, such as a corporate policy domain.

H. References

This proposal is based on the XACML definitions resulting from the June 2002 Face-to-Face meeting in Los Angeles, plus the recommendations on declarations of functions from the Schema Sub-committee meeting on 8 July. These are:

Anne Anderson

Last modified: Wed Jul 10 17:23:31 EDT 2002