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.

Note –

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: