How To: Creating a "Policy Assignment" ruleset (formerly "Web Mapping")

Version 1



    In my previous document How To: Creating a "Web Mapping" ruleset, I outlined how it is possible to create a ruleset which will assign "policies" (aka URL filtering rulesets) based on group membership in a clean fashion.


    In this new document, I will expand on what was demonstrated and use more of the flexability available in MWG7. The new "Web mapping" ruleset will dynamically assign (or set) the "User-Defined.Policy" property based on the name of the current rule. Doing this lowers the administrative overhead of managing the policies and rules, but will increase the complexity and understanding required. This method is very flexible, but is like a house of cards, meaning everything has to be in place in order for it to work. If you remove one piece it could all come crashing down.


    Other methods (and their pitfalls)

    There are various other methods for achieving this similar effects as the rule architecture I have outlined here. Here is a few examples of what I commonly see:


    User or Group based rules within the URL Filtering RuleSet

    I commonly see one-off rules to allow users/groups to specific categories or create a specific whitelist/blocklist. Using this method tends to complicate rules and may lead to inconsistent filtering if done incorrectly.



    Criteria for URL Filtering RuleSet is based on User or Group

    Another commonly used method is to set the criteria of the "URL Filtering" RuleSet to be "Authentication.UserGroups contains "GROUPNAME"". While this isnt a terrible concept, it can have many pit falls, such as:

        1. If user is apart of multuple filtering groups, they will get filtered twice
        2. Decision making is broken up and may create inconsistent URL filtering




    Goals of "Policy Assignment" architecture

    The primary goal of this architecture is to consolidate the decision making process for filtering users. Keeping the decision process down to a few RuleSets helps with isolation of problems, and ensures users will be filtered in a consistent fashion. Error handling has also been built into the architecture to help avoid the "why am I not being filtered?!" question from being asked.



    1. Authentication must be setup on the MWG in order for group based rules to work (not required for IP based rules).
    2. You should have read the original document How To: Creating a "Web Mapping" ruleset, this outlines fundamentals behind the concept.


    What's New

    1. To make the rules more dynamic, the criteria and events are based on the Rule name or RuleSet name. This is very important to recognize!
    2. The properties referenced are "Rules.CurrentRule.Name" and "Rules.CurrentRuleSet.Name".
    3. A new  "Policy Assignment" RuleSet for IPs has been added to demonstrate other use cases and flexibility of the Rule Engine.


    Policy assignment ruleset (aka Web Mapping)

    The new "Policy assignment" ruleset (formerly known as "Web Mapping") uses some new properties and methodology which make it more dynamic, and make it easier to manage. BUT it adds a bit of complexity.


    Policy Assignment (based on IP)

    It is very common for customers to have ranges of IP's for which they do not want to perform authentication. The following ruleset applies the "Policy assignment" concept to lists of IPs or IP ranges.


    Methodology to understand

        • The "User-Defined.Policy" is set based on the Rule name.
        • "Authentication.IsAuthenticated" is set to "true" in order to exempt the IP addresses from Authentication because only non-Authenticated clients should be authenticated (under default rules).

    1_2_2012-04-04_112852.png 10_2_2012-04-04_182051.png


    See: Policy Assignment - IP.xml


    Policy Assignment (based on Group/User list)

    This is the most common question we get in support, "How can we filter based on groups or users?". There are many ways to accomplish this, but in my opinion, this is the cleanest solution. If used correctly and understood it can be very powerful.


    Methodology to understand

        • Rule name, is equal to the group name you wish to filter based on.
        • Alternativley you can add users to a list, and they will also match.
        • "User-Defined.Policy" is set based on the in the event.
        • Rule event stays the same, the Rule name and the User list criteria should be changed if you need to duplicate the rule for new policies.





    See: Policy Assignment - Group_Users.xml


    Policy ruleset(s) for URL Filtering

    Now that the "User-Defined.Policy" property has been set, we must apply the "URL Filtering" RuleSet based on the "User-Defined.Policy".


    Methodology to understand

      • URL Filtering ruleset will only match if the "User-Defined.Policy" property equals the RuleSet name.




    See: Static - URL Filtering - Policies.xml

    Understanding the "Default" Policy container (catch-all)

    In order to ensure user's get filtered, a Default Policy container has been setup. This "catch-all" will accomplish two things:

    1. Apply a "Default" Policy to any users that have not explicitly been assigned a policy
    2. Account for misconfiguration or spelling mistakes in rules


    "Default" Policy assignment

    The default value for the "User-Defined.Policy" is set to "Default". So... if the user does not match on any of the IP or group based Policy assignment rules, they will fall to the "Default" URL Filtering RuleSet.




    If you create a Policy assignment rule that does not have a corresponding "filtering" ruleset. Then the user will fall to the Default ruleset. This is acheived by verifying a Policy has not already been applied.




    Accounting for misconfiguration

    In the event that a spelling mistake is made, or a Policy is referenced that doesnt exist, the following rule architecture will prevent any unfiltered access.




    The "Default" Policy uses the "User-Defined.PolicyFiltered" property, to determine if a user was filtered. If the user was NOT filtered by a policy, then they will receive the "Default" Policy.



    Building a dynamic URL Filtering RuleSet

    Coming soon...



    It would be beneficial to account for possible issues with implementing the Policy Assignment architecture. To do this you could do this in multiple ways.


    Modify the blockpages

    Block pages are the easiest way to troubleshoot unexpected filtering. You can add properties to the block page which will instantly tell you what policy the user recieved. In addition you can identify what rule/ruleset is blocking the user. The below screenshots show how this can be done.


    9_2012-03-28_185917.png 10_2012-03-28_190609.png


    Create a policy assignment log

    To troubleshoot any possible policy assignment issues, one could create a log (which should only be turned on for a specific test machine) to determine the cause for an incorrect assignment.


    12_2012-04-04_193156.png 5_2_2012-04-04_115648.png


    Below is an example of the output for the the log file (it was not blocked):


    Time: [04/Apr/2012:19:04:29 -0500]
    StatusCode: 301
    BlockID: 0
    Policy: Servers
    WasPolicyFiltered: true
    DoesPolicyExist: true
    LastRuleName: Block If Virus was Found
    LastRuleSetName: Gateway Anti-Malware
    FiredRules: SSL Scanner, Global Whitelist, Policy Assignment - IP...


    The entries "LastRuleName: Block If Virus was Found" and "LastRuleSetName: Gateway Anti-Malware" are set because they are the last evaluated rule, NOT because something was blocked. Take note that the BlockID equals 0.



    See: Policy Log.xml


    The above rule architecture is designed to make administrating the Web Gateway easier. In addition it may consolidate your rules and make them more comprehendible. Once this rule structure is put into place, identifying any user filtering issues should be a breeze .