MHonArc v2.5.0b2 -->
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]