User authentication is of central importance to the proper management of WinGate. By authenticating users, WinGate is able to control when and how they make connections to the Internet, and is able to delegate responsibility to those who are required to administrate WinGate through the WinGate Management console.
In WinGate, users and groups can be given permission to access, and control the configurations provided by the various modules that have been installed. Users can be given simple permissions that let them access and view particular module features, or they can be given more powerful rights which allow them to configure and change settings when required. When a user logs into the WinGate Management console and authenticates themselves with WinGate, these permissions will determine what they are able to see, access, and control.
Please refer to the Permissions system help for more information about WinGate permissions.
In order to control user access to the Internet, WinGate must first be able to identify the user who is making the connection. Since a user is always unknown when they initially make a connection through WinGate, there needs to be some way of WinGate distinguishing whether it already knows who is making the connection, or whether the user is unknown and so requires to be authenticated. WinGate provides this check and authentication of users through its Policy system and Web Access control rules.
Since all user access to the Internet through WinGate will be associated with the event of request taking place, you can use the Policy system to create a policy based on these request type events that will check to see whether or not the user has previously been authenticated by WinGate.
When a user has authenticated themselves with WinGate, they will be placed (for the duration of their Internet session) into a special Policy system group known as Authenticated users. Using the User/Group check policy item, the policy can be made to check whether the user associated with the request event is a member of this group. If the user is not a member, then the policy processing can be directed to a Result policy item that will force the user to authenticate themselves.
If the user has been previously authenticated in the session, then they will be a member of the Authenticated users group, and so the policy can be directed to an evaluation path that allows the process to continue.
This is illustrated in the policy worksheet example below.
In this example, whenever a client makes a ProxyRequest to the WWW Proxy Server (the event), the policy will then process a User / Group check policy item. This policy item has been configured to check if the user associated with the event, is a member of the Authenticated users group. If they are, then the policy will lead to the Result policy item that has been configured to Allow the request to continue. If they are not a member (i.e. have not already been authenticated) then the policy will take the No evaluation path which leads to the Result policy item that has been configured to force them to authenticate themselves.
An authentication policy can also be created to force users to authenticate themselves every time the request event happens, by simply processing an Result item that has been configured to Auth. However, since a single user Internet session can involve hundreds of request events, this can become unworkable for clients when they are accessing the Internet. Hence this simple authenticated users group check can provide a suitable solution for authenticating users when they are making Internet requests.
The availability of the Auth option in a Result policy item, is entirely dependent on the type of event you have chosen to base the policy on. Generally this will be available in policies based on proxy and server request oriented events, such as ConnectRequest, ProxyRequest, ServerRequest and Request.
When a client attempts to access the Internet through WinGate, you can create rules based on a range of criteria such as the website requested, the location the request is made from, the user or group making the request etc. When a Web Access Control rule specifies particular users as a criterion (not just Everyone) and the user making the request is unknown, WinGate will force the unknown user to authenticate themselves to determine if the rule should be applied.
The user database that has been selected to be used by WinGate will determine what type of authentication method WinGate will accept from the client.
WinGate provides support for Basic (plain text) authentication from clients, and NTLM authentication when using the WinGate user database.
When WinGate is set to use either of these two user databases, then it can require either Basic (Plain text) or NTLM authentication from clients when they are authenticating.
You can use basic Full-Text Searches against the page title and body to find matching articles. Use the following search modifiers to refine your query:
