XML access decision information

Edit online

By default, the rule evaluator automatically transforms into XML format any name-value pair attributes passed to it by the calling application. The attributes were identified as target access decision information (ADI) for the current evaluation.

When transforming the attribute to XML, the attribute name is used as the container name of the XML data item. The attribute value is converted into an XML value. The container name of an item of ADI equates to the XML element name in the XML definition. For example, the following XML data is generated for attribute name VPS_CREDIT_CARD with a string attribute value of 5517 3394 8324 0965:

<VPS_CREDIT_CARD>5517 3394 8324 0965</VPS_CREDIT_CARD>

The container name and XML element name in this case is VPS_CREDIT_CARD. The graphical user interface, the command-line interface, and the Verify Identity Access authorization API attribute list interfaces do not permit the administrator to define rules that contain invalid XML container names.

The application might pass entitlements or application context that are already formatted as XML for an access decision. In this case, the authorization rules evaluator expects the data to be of type azn_string_t and expects the format of the string to be XML. The attribute name must match the container name of the XML data item. If the names do not match, the evaluator does not evaluate the rule correctly.

The evaluator identifies XML format data by locating the less than (<) character at the beginning of the attribute value. If the attribute value does not begin with a less than character, the data is not considered to be an XML data item. The evaluator attempts to convert the data item to XML format automatically. This means of identification is used only on attributes or application context identified as target ADI for the access decision. Non-XML attribute values that start with a less than character cannot be used by the application. An error status is returned from the authorization decision. If the data is not correct XML, the XSL processor fails and returns an error to denote the failure.

Data items that must be defined in XML must be entirely defined in XML. Definition must not rely on the translation mechanism for non-XML items to generate the appropriate XML element name automatically. For example, to define an attribute to contain the XML definition of MY_CREDIT_CARD_NUM, you must add an attribute with the attribute name MY_CREDIT_CARD_NUM. The attribute value for MY_CREDIT_CARD_NUM is:

<MY_CREDIT_CARD_NUM>5517 3394 8324 0965</MY_CREDIT_CARD_NUM>

By defining the XML element as opposed to defining only its value, XML attributes can be added to the element definition. The addition does not affect the name by which the ADI is referred to when talking with data providers.

In the following definition of the XML item MY_CREDIT_CARD_NUM, the CardType XML attribute has the value of "visa". XML attributes are defined in the element start tag of the element to which they apply. XML attributes are equivalent to any other first-level child element of the XML object. To reference the attribute CardType, the required XPath is:

/XMLADI/MY_CREDIT_CARD_NUM/CardType

XML attributes must not be confused with the authorization API attributes and attribute lists that are used to carry data into and out of the authorization process.

<MY_CREDIT_CARD_NUM CardType="visa">
   5517 3394 8324 0965
</MY_CREDIT_CARD_NUM>

The ability to add XML attributes to an element definition is useful when it comes to defining a namespace for the data item. See XML namespace definitions.

If the ADI attribute contains multiple attribute values (string, XML, or any combination), the evaluator converts each attribute value as a separate instance of ADI. For example, the TxData attribute has values of 100 and 500. The evaluator inserts the following XML item declarations into the ADI XML document:

<TxData>100</TxData>
<TxData>500</TxData>

The policy administrator can then design an authorization rule that uses XSL language node selection statements to work with these two values independently. Alternatively, the authorization rule can add the values and compare the total with some predefined limit. If TxData is compared to a value, it is treated as a node set comparison where each TxData value is compared to the data. Success is indicated when any of the TxData values equal the target data. Node set comparisons have slightly different behavior than expected when using the != operator. In most cases, use the not() function instead. For information about when to use != and not() when comparing a node set, see Example: ADI from dynamic ADI retrieval services.