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] | [List Home]


Subject: RE: [xacml] FW: SAML AI 0076 - XACML Policy Transport


I think all it would take to define a generic "PolicyStatement"
is something the following:

  <xs:complexType name="PolicyStatementType">
     <xs:complexContent>
       <xs:extension base="saml:StatementAbstractType">
         <xs:sequence>
           <xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="PolicyType" type="xs:anyURI"
use="required"/>
       </xs:extension>
     </xs:complexContent>
  </xs:complexType>

Then add

  <element ref="saml:PolicyStatement"/>

to the list of choices for an "AssertionType", and define

  <element name="PolicyStatement" type="PolicyStatementStype">

This give SAML a generic "Policy Statement" syntax.

For XACML use, we then define two "PolicyType" URI's:

 urn:oasis:names:tc:xacml:1.0:policy - content is an XACML Policy
 urn:oasis:names:tc:xacml:1.0:policyset - content is an XACML PolicySet

Other policy languages could define other PolicyType URIs.

We would define <PolicyIdQuery> and <PolicyTargetQuery> similarly.

Would this be more generally useful?  I like the idea of a
standard "Policy Statement" and "Policy Query" included in SAML.

Anne
     
On 15 October, Hal Lockhart writes: RE: [xacml] FW:  SAML AI 0076 - XACML Policy Transport
 > From: "Hal Lockhart" <hlockhar@bea.com>
 > To: <xacml@lists.oasis-open.org>
 > Subject: RE: [xacml] FW:  SAML AI 0076 - XACML Policy Transport
 > Date: Wed, 15 Oct 2003 11:39:07 -0400
 > 
 > On the SAML call yesterday (10/14) the few people who expressed an opinion
 > felt that this was more appropriate to do in XACML. They felt that if we
 > wanted to introduce an abstract "policy" element which could contain any
 > kind of policy, not just XACML and then define the XACML constructs below
 > that, it might make sense to have SAML define abstract policy layer.
 > Otherwise the feeling was this was more appropriate to do in XACML.
 > 
 > Unless somebody feels the abstract policy layer is important, I suggest we
 > simply do it as described below. If at a future time there is a push for an
 > abstract layer, we can adjust accordingly. DOing it in the XACML TC will
 > also make it easier to deal with any interactions with other proposed 2.0
 > changes, such as to Target.
 > 
 > My feeling is that this will have to be a separate profile. Any opinions on
 > this?
 > 
 > Hal
 > 
 > > -----Original Message-----
 > > From: Hal Lockhart [mailto:hlockhar@bea.com]
 > > Sent: Tuesday, October 14, 2003 11:27 AM
 > > To: xacml@lists.oasis-open.org
 > > Subject: [xacml] FW: SAML AI 0076 - XACML Policy Transport
 > >
 > >
 > > I just posted this to the SSTC list. Comments from the XACML TC are more
 > > than welcome. Since the XACML TC F2F is before the SAML F2F, I will try to
 > > get a reading on today's call as to whether they will pursue this
 > > work item.
 > >
 > > Hal
 > >
 > > -----Original Message-----
 > > From: Hal Lockhart [mailto:hlockhar@bea.com]
 > > Sent: Tuesday, October 14, 2003 11:18 AM
 > > To: security-services@lists.oasis-open.org
 > > Subject: AI 0076 - XACML Policy Transport
 > >
 > >
 > > I thought at least some of this had been previously proposed within the
 > > XACML TC, but I can find no evidence for this. Therefore, this should be
 > > considered as coming from me as an individual. I will cross post it to the
 > > XACML list for comment.
 > >
 > > The basic idea of this proposal is twofold:
 > >
 > > 1) wrap an XACML <Policy> or <PolicySet> in a SAML statement so as to
 > > provide a common framework for header elements (version, issuer, validity
 > > interval, signature, etc.)
 > >
 > > 2) provide a SAML mechanism to retrieve policies by identifier or by
 > > <Target> evaluation.
 > >
 > > ------------------------------------------------------------------
 > > ----------
 > > ----------------
 > > The issue that needs to be decided first is whether this work
 > > should be done
 > > within the SSTC or the XACML TC. I do not see any strong argument either
 > > way. Since the work consists of extensions to the SAML schemas,
 > > it seems to
 > > me that the SSTC should have the right of "first refusal."
 > > ------------------------------------------------------------------
 > > ----------
 > > ----------------
 > >
 > > Details:
 > >
 > > A. XACML Policy Statement
 > >
 > > Define a new SAML Statement Type:
 > >
 > > <XACMLPolicyStatement> which inherits from StatementAbstractType (not from
 > > <SubjectStatementAbstractType>)
 > >
 > > It can contain either an XACML <PolicySet> or <Policy>
 > >
 > > B. XACML Policy Query
 > >
 > > Define two new SAML Query Types:
 > >
 > > <XACMLPolicyIdQuery>
 > >
 > > <XACMLPolicyTargetQuery>
 > >
 > > All inherit from <QueryAbstractType>
 > >
 > > The <XACMLPolicyIdQuery> contains one or more <PolicyId> or <PolicySetId>
 > > values. The response would return the matching Policies or PolicySets, if
 > > available.
 > >
 > > The <XACMLPolicyTargetQuery> contains an XACML request context which needs
 > > to only include the Subject, Resource and Action elements to be considered
 > > for policy Target matching. The response would return zero or
 > > more Policies
 > > or PolicySets which are potentially applicable to the decision. The
 > > responder could chose to match on some target elements and ignore others,
 > > but it would be required to return every potentially applicable policy or
 > > policyset it has. In other words, it can return a superset, but
 > > not a subset
 > > of the policies applicable to the decision.
 > >
 > > The existing SAML <Response> would be used to return an assertion
 > > containing
 > > XACML Policies and/or PolicySets as specified by the query.
 > >
 > > Note that the existing SAML <AssertionIdReference> could also be used to
 > > request an Assertion containing XACML POlicies, but this seems less likely
 > > to be useful than the Policy Id query.
 > >
 > > Hal
 > >
 > >
 > >
 > > To unsubscribe from this mailing list (and be removed from the
 > > roster of the OASIS TC), go to
 > > http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_w
 > orkgroup.php.
 > 
 > 
 > 
 > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.

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



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