cancel
Showing results for 
Search instead for 
Did you mean: 

How To: Creating a "Web Mapping" ruleset

How To: Creating a "Web Mapping" ruleset

Background

Often administrators of the Web Gateway will want to assign URL filtering policies based on group membership. This document outlines how to achieve this using Web Gateway 7, some of the terms used may refer to Web Gateway 6 (Webwasher) features for familiarity. Previously this would be done using the Web mapping feature in Web Gateway 6 (Webwasher).

Example

Alice is in group "Internet_Relaxed", Bob is in group "Internet_Strict", Carl is in neither group, and Doug is in both "Internet_Relaxed" and "Internet_Strict" (by mistake).

Web Mapping

Below is the end result of what the "Web Mapping" ruleset would look like. Prerequisite to using this ruleset, would be, you MUST be performing authentication.

1-webmapping.png

The users mentioned above would get the following "User-Defined.Policy" assigned:

Alice - Internet_Relaxed

Bob - Internet_Strict

Carl - none

Doug - Internet_Relaxed (because the relaxed rule is on top and action is "Stop Rule Set")

URL Filter policy containers

Below shows how to reference the "User-Defined.Policy" property.

2-policy-relaxed.png 3-policy-strict.png

Default container (catch all)

So what happens to Carl you might be asking...

When the "User-Defined.Policy" property is created, you can set a default value, so if a user does not perform authentication, or any other reason, they would fall to the "default" URL filtering ruleset.

4-user-defined-policy.png5-default-policy.png

Conclusion

I hope this helps in recreating what you were already doing in Web Gateway 6 (Webwasher), or if you are just starting out get different policies for different users.

The examples used above, are attached for your use. The "URL Filtering" containers should be configured to your needs (because the categories I have blocked/allowed might not match your needs). Also keep in mind, this is only one way to do this, there could be multiple ways, this is the most common, seen in support. Leave comments below if you see any room for improvement.

Comments
jsimon2010

Thanks Jon, this is a really nice solution and works very well.

franz_herrmann

Hi Jon,

as soon as the number of policies increases the next step of great flexibility in MWG7 can be fired:

Using the policy name and static strings as a kind of basename to calculate the list names you can condense the rulesets per policy to ONE ruleset with calculated list-names.

Use events to calculate

  • User-defined.policyWhitelistName to "URL-Whitelist -- " + User-defined.Policy
  • User-defined.policyBlacklistName to "URL-Blacklist -- " + User-defined.Policy

In the criteria use the Property List.OfWildcard.ByName( User-defined.policyWhitelistName ) to match the URLs against. The same for the Blacklist.

So you end up in ONE ruleset for any number of policies - BUT take care of defining the lists you need. Missing lists (typo errors or completely missing) will result in an internal Exception to the ErrorHandler with Error.ID of 10056 . You can catch this, e.g. send the admin an error notification, and return to the rest of your ruleset. Or end up with an internal error block page.

imtrying

Please forgive me I am very new to Webwasher.   What is the advantage of "mapping"?   Why cant you eliminate the step of assigning a user-defined value and simple set the URL filter criteria to only when authentication.usergroup contains "Internet relaxed"

Imtrying, the "mapping" method allows you to have more control over what policy the user will get. Take the "Doug" example into consideration. If you did not use the "mapping" method, then "Doug" would match on both policies.

Franz, that is a very creative way to (almost) dynamically assign policy, very cool.

~jon

franz_herrmann

Throughout the last days in a large MWG7 project we have even increased the scalability.

The challange:

  1. decisions to allow or block destinations can be based on Url.Host, Url (Deeplinks) or Categories
  2. these decisions are made in a hierarchy:

           - Global (complete organisation)

           - BusinessUnit (country independent), e.g. IT , PRODUCTION

           - Country (independant of country) , e.g.  DE, US

           - country specific Business Unit   , e.g.  IT-DE , PRODUCTION-US

           - business unit specific exceptions (A)  , e.g.  IT-Facebook, IT-Streaming

           - country unit and business unit specific exceptions (B), e.g. IT-DE-Radio, IT-DE-Executables

  3.  Directory group assignment for a specific user delivers unique Country and Business Unit, but can include multiple exceptions of type A and/or B

In addition to the dynamic calculated list names as in my previous comment the functions List.OfCategory.Join(ListA, ListB) and List.OfWildcard.Join and the ability to dynamically build Lists within the ruleset open the way to get a very compact ruleset for this challenge, where in Webwasher 6 more than 70 policies were needed.

~Franz

DBO

I am new to WW7, just out of the training class.  Care to publish an example using your dynamic rule set?  I am trying to get my head in all those new concepts.  WW6 was simpler but way less flexible...

ketchup

Prerequisite to using this ruleset, would be, you MUST be performing authentication.
However how do you handle requests without authentication (mixed environment)?
Many applications are unable to send authentications to the proxy and these requests should also fall in the "default" URL filtering ruleset.

You could bypass the 'Direct Proxy Authentication and Authorization' ruleset by the Destination-URL or the Client-IP, but I find no
way to do it generally for unauthenticated access. With this ruleset unauthenticated access will be blocked.

Hi Ketchup,

For my examples, yes, authentication is necessary. But, the same concept described in the article can be applied in many ways.

You could create a separate ruleset just for IP based policies. And assign policies exactly the same as shown in the Web Mapping ruleset except base them on IPs instead of usergroups.

-Jon

ketchup

Hi John

Example:
1.) Could the user be authenticated?
2.) If yes, assign it to a URL filterset ruleset (as you already have in your example).
3.) If no, assign the user to an 'Unauthenticated URL filterset rulebase.

For me point 3 is important, it should be applied if the authentication request fails
for any reasons. Unfortunately in our scenario we can not handle it IP-based or
URL-Destination based.

alessandro.ferr

Hi,

First, thanks for document, very good.

I have try install in my network...but my Web Mapping dont search URL Filtering custom, for example, URL Filtering -- GRPP_ITO.

Did you have a idea??

Thanks

Hi Alessandro,

This guide is a bit outdated, the new version can be found here:

https://community.mcafee.com/docs/DOC-3649

Best,

Jon

Version history
Revision #:
1 of 1
Last update:
‎02-15-2011 10:41 AM
Updated by: