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