[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] proposed amendment to Polar's resolution of PM-2-05
I'll take that as a friendly amendment, and I accept such friendly amendment. Cheers, -Polar On Fri, 5 Apr 2002, Beznosov, Konstantin wrote: > While generally agreeing with Polar's proposal for PM-2-05 resolution, I > have concern with the fact that his proposed text is vague in section > 8.1 about whether a PDP must or may list attributes that are needed by > the PDP to refine its decision: > ------------------------------------------------------------------------ > ------------------------------------------ > The PDP MAY return an "authorization decision" of "indeterminate" with > an > error code of "insufficient information", signifying that more > information > needed. In this case, the "authorization decision" will list any the > names > of any attributes of the subject and the resource that are needed by the > > PDP to refine its "authorization decision". > ------------------------------------------------------------------------ > ----------------------------------------- > > I suggest to amend the text of the resolution so that the above fragment > will read the following: > ------------------------------------------------------------------------ > ------------------------------------------ > The PDP MAY return an "authorization decision" of "indeterminate" with > an > error code of "insufficient information", signifying that more > information > needed. In this case, the "authorization decision" MAY list the names > of any attributes of the subject and the resource that are needed by the > > PDP to refine its "authorization decision". > ------------------------------------------------------------------------ > ----------------------------------------- > > The change makes a list of the attributes that are needed by the PDP to > refine its decision optional. > > Regards > Konstantin > > -----Original Message----- > From: Carlisle Adams [mailto:carlisle.adams@entrust.com] > Sent: Thursday, April 04, 2002 4:27 PM > To: 'xacml@lists.oasis-open.org' > Subject: [xacml] BATCH #2: E-mail vote to close issues... > > > > Hi, > > This e-mail vote is to officially close the following batch of issues. > The proposed resolutions are included. (As Anne has noted, there are > two resolutions given for PM-2-05 but one appears to be favoured. > Silence on this issue, therefore, indicates an acceptance of Polar's > proposed resolution.) If you have any objections to the resolutions on > any of these issues, please make them known to the list by responding to > this e-mail. A new resolution (or an amendment to the current > resolution) must be included in your posting. > > This e-mail vote closes at the end of the day on Thursday, April 11, > 2002. If no objections are posted by that time, the current batch of > resolutions will pass and the issues will be closed. > > Carlisle. > > > ---------- > From: Anne Anderson[SMTP:Anne.Anderson@Sun.com] > Sent: Thursday, April 04, 2002 12:45 PM > To: Carlisle.Adams@Entrust.com > Cc: Anne Anderson > Subject: Issues ready for e-mail vote > > MI-1-03, PM-2-05, PM-2-06, PM-8-05, PM-3-04 > > The final text for the proposed resolutions follows. Note that > there are two proposed resolutions for PM-2-05, although I think > mine got unofficially voted down. > > -Anne > ================================================================ > MI-1-03: Definition and purpose of Target (Anne) > > Proposed Resolution: a <target> element consists of three > predicates over elements in a SAML access decision request: one > over Subject, one over Resource, and one over Action. Any of > these predicates may be universal in that they may result in > "true" for "anySubject", "anyResource", or "anyAction". > > the <target> element in a <rule>, <policyStatement>, or > <policyCombinationStatement> has two purposes. First, it allows > <rule>s, <policyStatement>s, and <policyCombinationStatement>s to > be indexed based on their applicable subject, resource, and/or > action. Second, it allows a PDP to quickly and efficiently > reduce the set of <rule>s, <policyStatement>s, and > <policyCombinationStatement>s that must be evaluated in response > to a given access decision request. > > These intended purposes place three restrictions on what can be > included in a <target>. First, the predicates in a <target> must > be very efficient to evaluate. Second, each predicate in a > <target> must refer to only one of <subject>, <resource>, and > <action> (for indexing purposes). Third, each predicate in a > <target> must refer only to attributes that will always be > present in a SAML access decision request, since a <target> must > not return a result of "indeterminate". > > In a <rule>, the <target> element is logically part of the > <condition> element. Were indexing and efficiency not a concern, > the tests in the <target> could be incorporated into the > <condition>. The <target> element serves as the "first pass" > test for whether the rule applies: > > if (<target> == true) { > if (<condition> == true) { > return <effect>; > } > } > return <not applicable>; > =========================================================== > PM-2-05: Ensuring Completeness (Anne and Polar) > > Anne Proposed Resolution: A PDP must have a single base policy, > which may be either a <policyStatement> or a > <policyCombinationStatement>. The combiner algorithm in this > base policy, together with the tree of associated <policySet> and > <ruleSet> declarations, specifies the complete set of rules that > the PDP will use in evaluating an access decision request. > > Polar's Proposed Resolution: This resolution is against the > Version 12 document: > > I would suggest that we add a Normative section for Operational > Semantics. > I suggest that we put it between Section 8 and Section 9 (of course > altering the numbering of 9 to 10, etc). We may add more normative parts > > for other operational parts of the model. However, I think the only one > we > have to really worry about is the PDP, which is the XACML policy > language > evaluator. > > However, given the enormous flexibility of our model, I don't > think we can > actually state specify by XACML language alone, what happens behind the > PDP, a.k.a retrieving policies, attributes, (lazy evaluation) etc. It > appears that our PDP can be an interconnected collection of PRPs, PIPs, > and even other PDPs recursively. I think it best just to state the > compliance rules for a PDP for our viable language elements. > > The basic crux of the argument is that the when faced with > evaluating a > XACML policy or policy set it will do so in accordance to the semantics > that we lay out in this document. (I've kept the terminology somewhat > non-saml specific (i.e. "authorization decision request"), and apply > that > conformance to the SAML profile section. > > Here it goes: > > > 8.0 Operational Model (Normative) > > 8.1 Policy Decision Point (PDP) > > Given a valid XACML "policy statement" or a "policy set > statement", a > compliant XACML PDP MUST evaluate that statement in accordance to the > semantics specified in Sections 5, 6, and 7 when applied to an > "authorization decision request". The PDP MUST return a "authorization > decision", with one value of "permit", "deny", or "indeterminate". The > PDP MAY return an "authorization decision" of "indeterminate" with an > error code of "insufficient information", signifying that more > information > needed. In this case, the "authorization decision" will list any the > names > of any attributes of the subject and the resource that are needed by the > > PDP to refine its "authorization decision". > > Decision Convergence > > A client of a PDP MAY resubmit a refined authorization decision > request in > response to an "authorization decision" of "indeterminate" with an error > > code of "insufficient information" by adding attribute values for the > attribute names that are listed in the response. > > When the PDP returns an "authorization decision" of > "indeterminate" with > and error code of "insufficient information", a PDP MUST NOT list the > names of any attribute of the subject or the resource of the > "authorization > decision request" of which values were already supplied in the > "authorization decision request". Note, this requirement forces the PDP > to > eventually return an "authorization decision" of "permit", "deny", or > "indeterminate" with some other reason, in response to successively > refined "authorization decision requests". > > 9. Profiles (Normative, but not mandatory to implement) > > 9.2 SAML Profile > > A compliant SAML based PDP MUST reply to an SAML Authorization > Decision > Request with a SAML Authorization Decision in accordance with > operational > semantics of the PDP stated in Section 8.1. > ================================================================ > PM-2-06: Encapsulation of XACML policy (Anne) > > Proposed Resolution: The XACML syntax will not contain its own > security features. An XACML rule has no XACML-specified > encapsulation. An XACML policyStatement or > policyCombinationStatement MAY be encapsulated in a SAML > assertion. > ================================================================= > PM-8-05: How to return obligation via SAML (Michiharu) > > Proposed Resolution: Here is an authorization decision syntax > that returns obligation(s). SAML AuthorizationDecisionStatement > is extended to include xacml:obligations element by type > extension. "samle" namespace prefix is used to indicate SAML > extension for the decision assertion with obligation. Note that > the following example just shows the overview for simplicity. > > <saml:Assertion> > <saml:AuthorizationDecisionStatement Resource="aaa" Decision="Permit" > xsi:type="samle:AuthorizationDecisionStatementWithObligations"> > <saml:Subject> > <saml:NameIdentifier SecurityDomain="aaa" Name="Alice"/> > </saml:Subject> > <saml:Actions Namespace=" http://www.oasis-open.org/xmlactions"> > <saml:Action>Read</saml:Action> > </saml:Actions> > <xacml:obligations> > <xacml:obligation obligationId="myId"> > ... > </xacml:obligation> > </xacml:obligations> > </saml:AuthorizationDecisionStatement> > </saml:Assertion> > > > The following "samle" schema fragment defines an authorization > decision with obligations. > > <complexType > name="AuthorizationDecisionStatementWithObligations"> > <complexContent> > <extension base="saml:AuthorizationDecisionStatementType"> > <sequence> > <element ref="xacml:obligations"/> > </sequence> > </extension> > </complexContent> > </complexType> > =============================================================== > PM-3-04: Pseudo Code for Combiner Algorithms (Ernesto) > > Proposed Resolution: Java syntax should be used to describe any > mandatory-to-implement combiner algorithms. > ================================================================ > > -- > 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] | [Elist Home]
Powered by eList eXpress LLC