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. Contents 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: xacml:Request and xacml:Response schemas xacml:core [Policy] schema Function definition recommendations Anne Anderson Last modified: Wed Jul 10 17:23:31 EDT 2002