[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Revised Request and Response Context Schemas
Based on this morning's schema sub-committee conference call, I have revised the Request and Response Context Schemas. They are in the first attachment below. The second attachment has a request instance and policy instance example in the "Michiharu Standard Proposal Format". 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: Proposed Request and Response Context Schemas for XACML -->
<!-- Version: 1.2, 02/06/10 (yy/mm/dd) -->
<!-- Author: Anne Anderson -->
<!-- Source: /home/aa74233/docs/XACML/SCCS/s.ReqRespContextSchema.txt -->
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.oasis-open.org/committees/xacml/docs/draft-xacml-context.xsd"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; xmlns:xacml="http://www.oasis-open.org/committees/xacml/docs/draft-xacml-context.xsd"; elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- -->
<xs:element name="RequestContext" type="xacml:RequestContextType"/>
<xs:complexType name="RequestContextType">
<xs:sequence>
<xs:element ref="xacml:ContextPrincipals"/>
<xs:element ref="xacml:ContextResource"/>
<xs:element ref="xacml:ContextAction"/>
<xs:element ref="xacml:ContextOther"/>
</xs:sequence>
<!-- IDType must be a unique identifier -->
<xs:attribute name="RequestID" type="saml:IDType" use="required"/>
</xs:complexType>
<!-- -->
<xs:element name="ResponseContext" type="xacml:ResponseContextType"/>
<xs:complexType name="ResponseContextType">
<xs:choice>
<xs:element ref="xacml:Permit"/>
<xs:element ref="xacml:Deny"/>
<xs:element ref="xacml:Indeterminate"/>
</xs:choice>
<!-- RequestID must be copied from the request context
for which this is the response. -->
<xs:attribute name="RequestID" type="saml:IDType" use="required"/>
</xs:complexType>
<!-- -->
<!-- ContextPrincipals contains information about the
entities involved in making the access request -->
<xs:element name="ContextPrincipals" type="xacml:ContextPrincipalsType"/>
<xs:complexType name="ContextPrincipalsType">
<xs:choice>
<!--xs:element ref="xacml:ComplexPrincipal" minOcurs="1" maxOccurs="1"/-->
<xs:element ref="xacml:Principal" minOccurs="1" maxOccurs="unbounded"/>
</xs:choice>
</xs:complexType>
<!-- -->
<xs:element name="Principal" type="xacml:PrincipalType"/>
<xs:complexType name="PrincipalType">
<xs:sequence>
<xs:element ref="xacml:PrincipalID" minOccurs="0" maxOccurs="1"/>
<xs:element ref="xacml:Attribute" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<!-- ContextSeat examples: "j2se:CodeSource", "xacml:AccessSubject".
ContextSeat default value: "xacml:AccessSubject" -->
<xs:attribute name="ContextSeat" type="xs:anyURI" use="optional"/>
</xs:complexType>
<!-- -->
<!--xs:element name="ComplexPrincipal" type="xacml:ComplexPrincipalType"/-->
<!--xs:complexType name="ComplexPrincipalType"-->
<!-- Not yet defined: a relational tree structure of Principal -->
<!--/xs:complexType-->
<!-- -->
<xs:element name="PrincipalID" type="xacml:PrincipalIDType"/>
</xs:complexType name="PrincipalIDType">
<xs:choice>
<xs:element ref="xacml:NameIdentifier"/>
<!-- did we agree on the 'ds:key' here? -->
<!--xs:element ref="ds:KeyInfo"/-->
</xs:choice>
</xs:complexType>
<!-- -->
<xs:element name="NameIdentifier" type="xacml:NameIdentifierType"/>
<xs:complexType name="NameIdentifierType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Format" type="xs:anyURI" use="required"/>
<xs:attribute name="NameQualifier" type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- -->
<xs:element name="AnyURI" type="xs:anyURI"/>
<!-- -->
<xs:element name="AttributeDesignator" type="xacml:AttributeDesignatorType"/>
<xs:complexType name="AttributeDesignatorType">
<xs:sequence>
<!-- Holder is usually the PrincipalID element value when
Attribute is used in a Principal, so Holder is
optional in that context. -->
<xs:element ref="xacml:Holder" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="AttributeName" type="xs:string" use="required"/>
<!-- xacml:AttributeNamespace is the namespace authority
for the xacml:AttributeName -->
<xs:attribute name="AttributeNamespace" type="xs:anyURI" use="required"/>
<xs:attribute name="Issuer" type="xs:anyURI" use="optional"/>
<xs:attribute name="IssueInstant" type="xs:dateTime" use="optional"/>
<xs:attribute name="AttributeLocator" type="xs:string" use="optional"/>
</xs:complexType>
<!-- -->
<xs:element name="Holder" type="xacml:PrincipalIDType"/>
<!-- -->
<xs:element name="Attribute" type="xacml:AttributeType"/>
<xs:complexType name="AttributeType">
<xs:complexContent>
<xs:extension base="xacml:AttributeDesignatorType">
<xs:sequence>
<xs:element ref="xacml:AttributeValue"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- -->
<xs:element name="AttributeValue" type="xacml:AttributeValueType"/>
<xs:complexType name="AttributeValueType">
<xs:sequence>
<xs:any maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- -->
<xs:element name="ContextResource" type="xacml:ContextResourceType"/>
<xs:complexType name="ContextResourceType">
<xs:sequence>
<xs:element ref="xacml:ResourceSpecifier" maxOccurs="1"/>
<xs:element ref="xacml:Attribute" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- -->
<xs:element name="ResourceSpecifier" type="xacml:ResourceSpecifierType"/>
<xs:complexType name="ResourceSpecifierType">
<xs:sequence>
<xs:element ref="xacml:ResourceContent" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="ResourceURI" type="xs:anyURI" use="optional"/>
</xs:complexType>
<!-- -->
<xs:element name="ResourceContent" type="xacml:ResourceContentType"/>
<xs:complexType name="ResourceContentType">
<xs:sequence>
<xs:any maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- -->
<!-- ContextAction may be parseable into multiple actions,
but the interpretation is application-dependent -->
<xs:element name="ContextAction" type="xs:string"/>
<!-- -->
<!-- ContextOther is used for attributes associated with
entities that are not involved in making the access
request -->
<xs:element name="ContextOther" type="xacml:ContextOtherType"/>
<xs:complexType name="ContextOtherType">
<xs:sequence>
<xs:element ref="xacml:Attribute" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- -->
<xs:complexType name="DecisionType">
<xs:attribute name="ResourceName" type="xs:anyURI"/>
<xs:attribute name="Action" type="xs:anyURI"/>
</xs:complexType>
<!-- -->
<xs:element name="Permit" type="xacml:EffectDecisionType"/>
<xs:element name="Deny" type="xacml:EffectDecisionType"/>
<xs:complexType name="EffectDecisionType">
<xs:complexContent>
<xs:extension base="xacml:DecisionType">
<xs:sequence>
<xs:element ref="xacml:Obligation" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- -->
<xs:element name="Obligation" type="xacml:ObligationType"/>
<xs:complexType name="ObligationType">
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ObligationName" type="xs:anyURI"/>
</xs:complexType>
<!-- -->
<xs:element name="Indeterminate" type="xacml:IndeterminateType"/>
<xs:complexType name="IndeterminateType">
<xs:complexContent>
<xs:extension base="xacml:DecisionType">
<xs:sequence>
<xs:element ref="xacml:Advice" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- -->
<xs:element name="Advice" type="xacml:AdviceType"/>
<xs:complexType name="AdviceType">
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="AdviceName" type="xs:anyURI"/>
</xs:complexType>
</xs:schema>
Title: RequestContext and Policy Proposal
Version: 1.1, 02/06/10 (yymmdd)
Author: Anne Anderson
Source: /home/aa74233/docs/XACML/SCCS/s.ReqContextProposal.txt
EXAMPLE ACCESS REQUEST DESCRIPTION IN ENGLISH
Read and write access has been requested for the file
"/net/saguaro/home/zoe/status.txt".
The user executing the thread from which the access request was
generated was authenticated as both
o "cn=Anne,ou=SunLabs,o=Sun,c=US", and as
o "Anne.Anderson@Sun.COM"
The executing code for the thread that generated the access
request was downloaded from "http://java.sun.com/jdk1.4/classes";.
The code was signed by two certificates with subject names
o "cn=J2SESigner,ou=JavaSoft,o=Sun,c=US", and
o "cn=SunSigner,o=Sun,c=US".
PROPOSED XACML CONTEXT SPECIFICATION OF THE ABOVE
<xacml:RequestContext>
<xacml:ContextPrincipals>
<xacml:Principal ContextSeat="j2se:AccessSubject">
<xacml:NameIdentifier Format="itu:X500DistinguishedName">
"cn=Anne,ou=SunLabs,o=Sun,c=US"
</xacml:NameIdentifier>
</xacml:Principal>
<xacml:Principal ContextSeat="j2se:AccessSubject">
<xacml:PrincipalID>
<xacml:NameIdentifier Format="ietf:RFC822Name">
"Anne.Anderson@Sun.COM"
</xacml:NameIdentifier>
</xacml:PrincipalID>
</xacml:Principal>
<xacml:Principal ContextSeat="j2se:CodeSource">
<xacml:PrincipalID>
<xacml:NameIdentifier Format="ietf:URL">
"http://java.sun.com/jdk1.4/classes";
</xacml:NameIdentifier>
</xacml:PrincipalID>
<xacml:Attribute AttributeName="SignedBy"
AttributeNamespace="j2se:Policy"
<xacml:AttributeValue>
"cn=J2SESigner,ou=JavaSoft,o=Sun,c=US"
</xacml:AttributeValue>
<xacml:AttributeValue>
"cn=SunSigner,o=Sun,c=US"
</xacml:AttributeValue>
</xacml:Attribute>
</xacml:Principal>
</xacml:ContextPrincipals>
<xacml:ContextResource>
<xacml:ResourceSpecifier ResourceURI="file:/net/saguaro/home/zoe/status.txt"/>
</xacml:ContextResource>
<xacml:ContextAction>
"read,write"
</xacml:ContextAction>
</xacml:RequestContext>
SAMPLE POLICY IN ENGLISH
Grant "read,write" access to resource
"file:/net/saguaro/home/zoe/*" if the user identity associated
with the thread from which the request was issued is
"Zoe@Sun.COM" or if the executing code was signed by
"cn=J2SESigner,ou=JavaSoft,o=Sun,c=US".
XACML POLICY SPECIFICATION OF THE ABOVE
The following two rules are included in an xacml:policyStatement
where the ruleCombiningAlgId allows access if any rule allows
access.
<xacml:rule ruleId="sunlabs:rule9" effect="Permit">
<xacml:target>
<xacml:subjects>
<xacml:AttributeDesignator AttributeName=
"RequestContext/ContextPrincipals
/Principal[@ContextSeat="xacml:AccessSubject"]
/PrincipalID/NameIdentifier[@Format="ietf:RFC822Name"]"
AttributeNamespace="http://www.oasis-open.org/committees/xacml/docs/draft-xacml-context.xsd"/>
<xacml:AttributeValue>
"Zoe@Sun.COM"
</xacml:AttributeValue>
</xacml:subjects>
<xacml:resources>
<xacml:AttributeDesignator AttributeName=
"RequestContext/ContextResource
/ResourceSpecifier[@ResourceURI="file:/net/saguaro/home/zoe/*"]"
</xacml:Attribute>
</xacml:resources>
<xacml:actions>
<xacml:Attribute AttributeName=
"RequestContext/contextAction/Action">
<xacml:AttributeValue>
"read,write"
</xacml:AttributeValue>
</xacml:Attribute>
</xacml:actions>
</xacml:target>
</xacml:rule>
<xacml:rule ruleId="sunlabs:rule10" effect="Permit">
<xacml:target>
<xacml:subjects>
<xacml:Attribute AttributeName=
"RequestContext/ContextPrincipals
/Principal[@ContextSeat="j2se:CodeBase"]
/Attribute[@AttributeName="SignedBy" and
@AttributeNamespace="j2se:Policy"]">
<xacml:AttributeValue>
"cn=J2SESigner,ou=JavaSoft,o=Sun,c=US"
</xacml:AttributeValue>
</xacml:Attribute>
</xacml:subjects>
<xacml:resources>
<xacml:Attribute AttributeName=
"RequestContext/ContextResource
/ResourceSpecifier[@ResourceURI="file:/net/saguaro/home/zoe/*"]"
</xacml:Attribute>
</xacml:resources>
<xacml:actions>
<xacml:Attribute AttributeName=
"RequestContext/contextAction/Action">
<xacml:AttributeValue>
"read,write"
</xacml:AttributeValue>
</xacml:Attribute>
</xacml:actions>
</xacml:target>
</xacml:rule>
HOW XACML POLICY SPECIFICATION REFERS TO EACH ATTRIBUTE IN XACML CONTEXT
In the example above, I have used full XPATH expressions (to the
best of my ability) starting from RequestContext to refer to
attributes in the request context.
Under the xacml:rule/target/subjects section of a rule, it should
be possible to assume the root is
RequestContext/ContextPrincipals/Principal, and then use an XPATH
expression to navigate from there. Similarly, it should be
possible to assume under xacml:target/resources that the root of
the XPATH is RequestContext/ContextResource/ResourceSpecifier. I
think the choice of whether to allow such a "shortcut" is the
least of the issues we need to work out.
In the xacml:rule/conditions sections of a rule, it would be
necessary to specify the root explicitly (as I did in my
examples), since there is no context to narrow it.
DESIRABLE FINAL DECISION
1. Allow multiple Principals under ContextPrincipals,
distinguished by an XML attribute that identifies the role the
principal plays in making the access request. The type of
this XML attribute is "anyURI".
This XML attribute is tentatively named "ContextSeat" [but I
don't care what we end up calling it].
There is a default value for this attribute that identifies
the subject entity that is most immediately behind the access
request.
The default value is tentatively named "xacml:AccessSubject"
[but I don't care what we end up calling it].
2. Only one resource is allowed in a RequestContext.
I think Michiharu would like there to be a <Resource> element
between the <ContextResource> element and the
<ResourceSpecifier> element, as in the following example:
<ContextResource>
<Resource>
<ResourceSpecifier/>
<Attribute/>
<Attribute/>
</Resource>
</ContextResource>
but it seems to me that the <Resource> element is redundant
so I have omitted it in my schema. If Michiharu can explain
why it is better to have <Resource> under <ContextResource>,
then I am happy to include it.
3. Attribute[Designator] has XML attributes called AttributeName
(string) and AttributeNamespace (anyURI), just as SAML does.
The schema committee voted to accept this, and I think it is
OK (now that I know it comes from SAML, and will make SAML
mapping easier).
All other Attribute[Designator XML attributes are optional.
The Holder element in an Attribute that is part of a
RequestContext/ContextPrincipals/Principal is optional. If it
occurs, it MUST match any PrincipalID element in the same
Principal.
4. ContextAction is separate from ContextResource, and is a
single string. The string may be parseable into separate
actions, but this is application-dependent and not apparent to
the PDP. Since we have decided to have only one resource in
the RequestContext, there is no problem having actions be
under a separate element from the resource to which they
apply.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC