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

*Subject*: **FAQ: what are the basic Assertion functions, and how are they provided?**

*From*:**Anne Anderson <Anne.Anderson@sun.com>***To*: dipal-discuss@lists.oasis-open.org*Date*: Thu, 15 Dec 2005 12:05:41 -0500

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

**Follow-Ups**:**Re: [dipal-discuss] FAQ: what are the basic Assertion functions, and how are they provided?***From:*Frank McCabe <frank.mccabe@us.fujitsu.com>

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