Overview
Policies are currently the most intricate part of any WinGate setup (My opinion). However, once you have the basic concepts firmly in hand it becomes very very easy.
The first thing to know is that there are two distinct groups of policies that can act together. The first is the Default (System) Policies. You will find them on the "Users" tab in GateKeeper. Those policies are used if no others are available. By default, they freely grant access.
The second set is the per service policies. They are usually more specific as they have inherently more infomration about the protocol they are working with. You will find these on the policy tab in each service.
Those two policies 'groups' can interact with eachother in three different ways from a Service perspective. For system policies:
May be used instead - either version of the policy can grant access
MUST also be granted - the system policies and the service policies must grant access
Are ignored - the system policies are ignored. Only the service policies apply
Now, to implement a policy you must first determine where you want to implement it. For example - some policies you might want to apply irrespective of the service that is in use. (Traffic limits for a user, for example). Others, you might want to block specific URLs, in which case the Web Proxy is the best place to do so. This is sometimes a bit tricky, and I've found that a rough flow diagram helps here sometimes; especially when you are dealing with a very complex setup.
The next thing to know is that the policies are permissive. If any policy grants the user the right to use / do something -
even if another policy later denies it the user will have the right to access that resource. This becomes very important when you consider the interaction between Service Policies and System Policies.
Advanced Filters and Criterion seem complicated, but in truth that is the way to get the most out of policies. It's very easy as well, though.
Filters are OR statements. So, if you read them top to bottom they will say
- Code:
if Filter1 is granted or if Filter2 is granted or if Filter3 is granted then the user has rights to this resource.
When you delve a bit deeper, Criterion within a filter are AND statements.
- Code:
if (Filter1.Criterion1 is granted and Filter1.Criterion2 is granted and Filter1.Criterion3 is granted ) OR (Filter2.Criterion1 is granted) OR (Filter3.Criterion1 is granted) then the user has rights to this resource.
TipsAlright. Armed with all of that there are a few tips to setting them up. First, try to ensure that your traffic is going through the most appropriate service. That gives you the most control over your policies. As you are using WGIC, redirecting that through your webproxy (By setting Intercepts on the WWW Proxy Service) gives you access to the proxy's policies. You can then define your policies there.
Secondly, you can have the same user in a policy multiple times with different types of rights granted. For example - if I want all my users to authenticate when visiting the entire web except for the Qbik webpages I would create two policies for the "Everyone" user.
The first would be:
- Code:
Everyone: User must be authenticated
The second would be:
- Code:
Everyone: User may be unknown
Advanced Filter + Criterion: Right is granted if HTTP URL contains "qbik.com"
For your setup
What you want to do is create a series of policies for the different users and groups that you have. The easiest way to do this would probably be to divide your users into two groups, those that have rights to go everywhere and those that have restricted access.
Then, you create two policies. One for the group "Restricted" which specifies which sites they are restricted in. Another for the group "Free" which does not specify anything.
The group your users belong to will determine which sites they can then visit. For this to work you will have to be able to associate a given session with a given user. This can be done by an assumption or by actually authenticating the user. (That's cover quite well in the helpfile)
However, one important thing to note is this:
Certain authentication schemas only give you an assumed status. HTTP Basic and most of the email-authentication schemas are treated as "Assumed". So, if you policies will require Authentication you should use a stronger form, such as Java Client, WGIC or NTLM.
Okay. Hope that helps. Post back if you need more.