[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dipal-discuss] FAQ: what are the basic Assertion functions,and how are they provided?
Hi Frank, These are good points. I think they touch partly on expressivity requirements for a policy Assertion language and partly on an appropriate division of functionality between the Assertions and the policy framework in which Assertions are used. For issuer information, I envision this expressed at the policy framework level (or even the policy metatdata level - the policy envelope), and not the Assertion level. An entire policy, including all its Assertions, would be issued by the one issuer identified at the policy or policy metadata level. Since we are discussing an Assertion language to be used within some externally-specified policy framework language, I did not include this functionality in the list of "basic functions" for an Assertion itself. For subject information, there are at least three approaches. 1) The identity of the subject is not always relevant for a web services policy, so I don't think all policies will include a "subject". 2) A subject can be associated with a policy by encapsulating the policy in a SAML Assertion; this mechanism might be appropriate for some policies. 3) With WS-PolicyConstraints or a similar Assertion language, a specific set of policy Assertions can be tied to a particular subject (or subject characteristic) by including an Assertion such as "subject-id == 'Anne'" in a group of Assertions connected by "AND". Thus the group of Assertions will be true only when the subject is "Anne" AND the other Assertions are also true. Assertions applying to other subjects could be listed in other AND'd groups, and the various groups could be connected with "OR" or "XOR". The "AND", "OR", and "XOR" operators are provided by the policy framework language, and not by the Assertion language. Does this satisfy your requirements, or do you see this differently? Regards, Anne Frank McCabe wrote On 12/17/05 17:29,: > I think that you are missing some key aspects of policies > Notably the subject of the policy (the owner of the policy if > you will) and who is the subject of the policy. > > In our discussions, we distilled policy into "a constraint on the > behavior of some owned resource from the perspective of a stakeholder" > This conceptualization seems completely missing below. > > Frank McCabe > > On Dec 15, 2005, at 9:05 AM, Anne Anderson wrote: > > >>An Assertion in a Boolean policy framework, regardless of the >>Assertion >>language, must support 3 basic functions: >> >>1) IDENTIFY: Provide the identity of the policy variable (policy >>vocabulary item) that the Assertion covers. >> >>2) TEST: When provided with a value for the policy variable it covers, >>return a value of TRUE or FALSE depending on whether the value >>satisfies >>the Assertion. >> >>3) INTERSECT: Provide a way to compare two Assertions that cover the >>same policy variable and return either an error indicating "Not >>compatible" or return some representation of the one or more values >>that >>are mutually compatible for the two Assertions (the values for which >>both Assertions will return TRUE). >> >>COMPARISON OF DOMAIN-SPECIFIC VS DOMAIN-INDEPENDENT APPROACHES >>============================================================== >> >>Let's compare how these functions are provided using domain- >>specific and >>domain-independent policy Assertion languages. >> >> Example Consumer Service Assertion: the guaranteed bandwidth must be >>at least 4800bps. >> Example Provider Service Assertion: the guaranteed bandwidth is >>14400 bps. >> >>A. DOMAIN-SPECIFIC >>================== >> >> Consumer Service Assertion: >> <ns:GuaranteedBandwidth>4800</ns:GuaranteedBandwidth> >> >> Provider Service Assertion: >> <ns:GuaranteedBandwidth>14400</ns:GuaranteedBandwidth> >> >> 1) IDENTIFY: The QName of the Assertion element: >>"ns:GuaranteedBandwidth". >> >> 2) TEST: There is a problem here. The consumer is happy with any >>value greater than or equal to the GuaranteedBandwidth, whereas the >>provider is happy only with the one value provided. So the special >>code >>module must know whether the input value is from a consumer policy or >>from a provider policy in order to return the right answer. For the >>consumer, the special code module must implement a "greater than or >>equal to" test, whereas for the provider, the special code module must >>implement an "equal to" test. >> >> If the Assertion is to be used to test a policy value that occurs >>in an actual message, then the special code module must know how to >>locate the policy value in a message and use it as input. >> >> 3) INTERSECT: A special code module must be written that can take >>two >>ns:GuaranteedBandwidth Assertions and determine which values will >>result >>in TRUE from both Assertions, or else return an error indicating >>"Incompatible". A way must be provided to represent that set of >>values >>that will return TRUE. Again, this special module must know which >>Assertion comes from a consumer and which comes from a provider in >>order >>to implement the correct computation. >> >>B. DOMAIN-INDEPENDENT >>===================== >> >> Consumer Service Assertion: >> >> <xacml:Apply FunctionId="integer-greater-than-or-equal"> >> <xacml:AttributeSelector >> InputContextPath="//ns:GuaranteedBandwidth/text()" >> DataType="integer"/> >> <xacml:AttributeValue >> DataType="integer">4800</xacml:AttributeValue> >> </xacml:Apply> >> >> Think of this as the function: >> >> //ns:Bandwidth/text() >= 4800 >> >> Provider Service Assertion: >> >> <xacml:Apply FunctionId="integer-equal"> >> <xacml:AttributeSelector >> InputContextPath="//ns:GuaranteedBandwidth/text()" >> DataType="integer"/> >> <xacml:AttributeValue >> DataType="integer">14400</xacml:AttributeValue> >> </xacml:Apply> >> >> Think of this as the function: >> >> //ns:Bandwidth/text() == 14400 >> >> 1) IDENTIFY: The "InputContextPath" value of the AttributeSelector: >>"//ns:GuaranteedBandwidth/text()". If an XACML AttributeDesignator >>were >>used instead, it would be the AttributeId value (perhaps >>"...:GuaranteedBandwidth"). >> >> 2) TEST: There are standard functions for >>"integer-greater-than-or-equal" and "integer-equal". The input value >>and the "AttributeValue" are passed to these standard functions as >>parameters, and the answer is returned. >> >> If the input value occurs in a message, then the InputContextPath >>would be an XPath expression that selects the policy value, so the >>message can be supplied as input, and the TEST can be applied directly >>to it, with the semantics "Does this message satisfy this Assertion?" >> >> 3) INTERSECT: The standard function intersection table is consulted >>for the entry that corresponds to ">=" and "==": >> >> First function Second function If Result >> -------------- --------------- ------ ------ >> x >= y x == z z >= y z >> z < y INCOMPATIBLE >> >>In this case "14400 >= 4800" is true, so the result is 14400. >>Calculating this intersection is a simple integer test. The other >>function intersection functions are similar trivial to compute. >> >>The result is either an error indicating "Incompatible", or can be >>expressed using an Assertion that describes the mutually acceptable >>values. In this case, the resulting Assertion will be the same as the >>provider's Assertion. Computing a new mutually compatible Assertion >>makes it easy to compare Assertions from multiple policies: two are >>compared, the result is compared with the next policy's Assertion, >>that >>result is compared with the next policy's Assertion, .... >> >>For simplicity of presentation, the example above omits the function >>that tests whether the policy variable has a single value or multiple >>values. Particularly when testing an Assertion directly against a >>message, this function is very helpful, since there may be more >>than one >>instance of a given element in the message. That situation may either >>be an error, or it may be the case that the policy writer is happy so >>long as at least one of the values satisfies the function. >> >>Regards, >>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 >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: dipal-discuss-unsubscribe@lists.oasis-open.org >>For additional commands, e-mail: dipal-discuss-help@lists.oasis- >>open.org >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dipal-discuss-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: dipal-discuss-help@lists.oasis-open.org > -- 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]