PolicyFilter -- Preprocess Policies Prior Being Used

Another extension of ArpRepository^? as provided by MAMS group is the notion of PolicyFilter. It allows selective preprocessing of the policies (ARPs) prior they are being used by the system. Policies fed to an instance of PolicyFilter are guaranteed to be active and effective (i.e. it will be used to be processed by the system if there were no PolicyFilter in-place), hence PolicyFilter is given the first chance to preprocess them.

Example of PolicyFilter usage:

   <ReleasePolicyEngine>
      <ArpRepository implementation="au.edu.mq.melcoe.mams.sharpe.shib.aa.arp.provider.MAMSFileSystemArpRepository">
         ...
         <PolicyFilter implementation="au.edu.mq.melcoe.mams.sharpe.shib.aa.arp.policyfilter.provider.PolicyTypeFilter" allows="read,update" enable="false">
             <PolicyType>sitePolicy</PolicyType>
             <PolicyType>userPolicy</PolicyType>
             <!-- <PolicyType>groupPolicy</PolicyType> -->
         </PolicyFilter>
         ...

The above allows "read,update" and disables "create, delete" operations on site and user policies only, disabled initially which means the application will turn it on later when needed (appropriate API is provided for this). Other type of policy is ignored (i.e. groupPolicy is "unknown" to the system, hence the above PolicyFilter effectively reverts GroupARP implementation making ShARPE's extension disabled).

Complex PolicyFilter can be implemented for example to only process or release policies upon existence of certain attributes, or dynamically adding/deleting rules or attributes contributing to certain policies prior them being fed to ArpEngine^?.

Careful thoughts should be given when PolicyFilter is enabled. It will provide dynamic availability of policies to the system and could result in confusing outcome (i.e. the result of one filter could very well wipe off the availability of policy for the next filter, hence the output)

-- BrucLiong - 24 Apr 2006
to top