Policy Implementation

As the first step of policy implementation, the API abstracts how a resource is represented by mandating that any resource be represented in a string format. For example, on a web server, resources may be represented as URLs. The policy evaluation engine cares only about the relative relevance of one resource to other. Five relative relevances are defined between two resources:

• exact match

• no match

• subordinate match

• superior match

• exact pattern match

Having represented the resources in string format, the service developer must provide interfaces that establish the relevant relationship between resources.

Exact pattern match is a special case where resources may be represented collectively as patterns. The information is abstracted from the policy service and the comparison operation must take a boolean parameter to trigger a pattern matched comparison. During the caching of policy information, the policy engine does not care about patterns, whereas during policy evaluation, the comparisons are pattern sensitive.

The service developer must also provide a method to extract the root of the given resource. For example, in a URL, the protocol:// AcceessManager-HostName.domain_name:port portion represents the root. The three functions (has_patterns , get_resource_root and compare_urls) are specializations of resource representations. The set of characteristics needed to define a resource is called a resource trait. Resource traits are taken as a parameter during service initialization in the am_resource_traits_t structure. Using the resource traits, the policy service constructs a resource graph for policy evaluation. In a web server policy sense, the relation between all the resources in the system spans out like a tree with the following being part of the root tree:

protocol:// AcceessManager-HostName.domain_name : port/