Methods of providing ADI to the rules evaluator

A resource manager application can provide ADI from the resource manager to the rules evaluator in one of two ways. One method is to add the attributes to the application context parameter. The other method is to configure the rules evaluator to supply the missing ADI to the authorization engine only when it is explicitly requested.

The first method is to provide the ADI by adding the attributes to the application context parameter passed to the azn_decision_access_allowed_ext() method. The problem with this method is that the resource manager must know which ADI is going to be needed by a particular access decision. Alternatively, you can provide all the ADI for all known rules to the authorization engine for every access decision call regardless of whether a rule is involved in the decision.

The first method might be acceptable and even desirable for a smaller set of ADI. However, for a larger and more varied set of possible ADI, a second method is needed. You can configure the resource manager to supply the missing ADI to the authorization engine only when it is explicitly requested. With this method, the authorization engine can be configured with a set of ADI prefixes that can be provided by the resource manager upon request. The authorization engine fails the access decision and notifies the resource manager of the ADI it needs in a permission information attribute returned by the azn_decision_access_allowed_ext() method. The attribute contains a list of the ADI that is needed to successfully evaluate the rule. The ADI was not found in the application context that was passed in. The ADI also did not have a prefix that matches those prefixes that the resource manager identified as its own.

The permission information attribute is named azn_perminfo_rules_adi_request and contains a text attribute value for each item of ADI required. The resource manager looks for this attribute when the access decision fails. When it is present, the resource manager scans the list of ADI names in the attribute and gathers the requested data to try the access decision with this additional data again. If the requested data cannot be provided, the resource manager must deny access and log the problem as a failure due to insufficient rules data. The requested list contains only the ADI items that are identified as being provided by the resource manager. The unique prefix added to the attribute name is used to identify the ADI. All resource managers that provide data to the evaluation process in this manner must define a unique prefix by which their ADI data set can be identified.

Permission information is returned to a resource manager application only when the authorization client was configured that way. To activate the return of the azn_perminfo_rules_adi_request permission information attribute, the name of this attribute must either be added to the azn_init_set_perminfo_attrs initialization attribute or the equivalent permission-info-returned entry in the [aznapi-configuration] stanza.

The ADI prefixes that are recognized by the resource manager can be configured using the resource-manager-provided-adi entry or the azn_init_resource_mgr_provided_adi initialization attribute. See resource-manager-provided-adi and for the initialization attribute, see Authorization C API Developer Reference.

The authorization engine attempts to anticipate the need to request information from the resource manager by obtaining the rule policy object on the protected object early in the access decision process. The authorization engine then compares the required ADI in the rule with the ADI names in the application context parameter that is passed by the resource manager. The ADI names, which are missing from the application context and which are specific to the resource manager, are added to the returned permission information object.

ADI prefixes must be unique to identify them as resource manager ADI and to avoid conflict with ADI provided in the credential from the authorization engine or from an external data provider.