**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.