Skip to main content
Skyhigh Security

Authentication for Transparent Modes

When configuring authentication for the transparent modes, the settings on the browsers that are used for sending requests to Web Gateway need to be modified. A suitable rule must also be implemented on Web Gateway.

Modifying the browser settings

To enable authentication for the transparent router or bridge mode, the settings of each web browser that is used for sending requests must be configured to let it trust Web Gateway.

If NTLM or Kerberos is also configured as the authentication method on Web Gateway, the authentication process is handled internally, without asking the user to authenticate.

  • When using Microsoft Internet Explorer, you need to modify the security settings by:
    • Configuring your local intranet as a security zone
    • Adding Web Gateway as a website to this zone
      This is done by specifying a URL with an IP address or a fully qualified domain name, for example, http://10.10.69.73 or http://*.mcafee.local.
    • Configuring automatic logon for all websites in the zone as the security setting for user authentication

      You can configure this under Internet Options, using the Local Intranet and Security Settings - Local Intranet Zone windows.

      If group policies can be configured for a browser, you can also use the Group Policy Management Editor together with the Site to Zone Assignment List and the Logon Options window.
       
  • When using Mozilla Firefox, you need to configure an IP address or a fully qualified domain name for Web Gateway under about:config as the value of the network.automatic-ntlm-auth.trusted-uris parameter, for example,10.10.69.73 or mwgappl.yourdomain.local.

For more information, refer to the documentation of the respective web browser.

Library rule set for transparent modes

The recommended library rule set for the transparent router or bridge mode is Authentication Server (Time/IP Based Session).

It has two nested rule sets:

  • Check for Valid Authentication Session
  • Authentication Server

Differing from the authentication process that is performed for the explicit proxy mode, this rule set handles authentication by creating an authentication session when a user who sent a request for web access is successfully authenticated.

Subsequent requests that this user sends are processed without requiring authentication again as long as this session is still valid. The default session length is 600 seconds.

Using this rule set in a configuration where Citrix is installed or workstations are shared can lead to the following situation: User A sends a request, is authenticated, and an authentication session is created. Later on, user B sends a request from the same workstation and is still allowed to continue with user A's session.

Authentication Server (Time/IP Based Session) rule set

This rule set serves as a container for the two nested rule sets and has no rules of its own.

Check for Valid Authentication Session nested rule set

This rule set contains a rule that checks whether a valid session exists for a user who sends a request from a client. Session information is stored in an internal session database. It includes the user name, the IP address of the client, and the session length.

If a valid session exists, processing of the request is continued for the remaining rules and rule sets that are configured. If no valid session exists, the request is redirected to the authentication server.

Authentication Server nested rule set

This rule set contains a rule that lets authentication be performed for a user whose request has been redirected to the authentication server. If the authentication was successful, a session is created for this user in the session database.

The method used by default for evaluating the user's credential is comparing them to the information that is stored in the internal user database. You can replace this method with a different method, for example, LDAP or NTLM.

Modifying the rule set for transparent modes

When configuring authentication for transparent modes, you can modify the library rule set to adapt it to the needs of your network.

This includes:

  • Modifying the authentication server URL
  • Changing the authentication method
  • Enabling the ideal conditions rule
  • Increasing the session TTL
Modifying the authentication server URL

If you have modified the security settings of the browsers that are used for sending requests to Web Gateway by configuring your local domain as a security zone, you can include Web Gateway as a website in this zone by specifying a URL with an IP address or fully qualified domain name for it.

In this case, you also need to modify the URL of the authentication server, which by default contains an IP address for Web Gateway, by inserting the name of your local domain.

The authentication server URL is dynamically generated for an appliance that Web Gateway runs on. As there can be several Web Gateway appliances in a configuration, the IP address cannot be static, but must be configured dynamically, which is done using internal configuration properties.

You can modify this URL under the IP Authentication Server settings, which appear next to the Authentication.Authenticate property in the Redirect clients that do not have a valid session to the authentication server rule of the Check for Valid Authentication Session rule set.

By default, the URL looks like this:

http://$<propertyInstance useMostRecentConfiguration="false"
propertyId="com.scur.engine.system.proxy.ip"/>$:$<propertyInstance
useMostRecentConfiguration="false" propertyId="com.scur.engine.system.proxy.port"/>$

Shown in human readable format, a particular authentication server URL could be:

http://10.10.69.71:9090

After adapting the URL to the browser settings that have your local domain configured within a security zone, it looks like this:

http://$<propertyInstance useMostRecentConfiguration="false"
propertyId="com.scur.engine.system"/>$.yourdomain.local:$<propertyInstance
useMostRecentConfiguration="false" propertyId="com.scur.engine.system.proxy.port"/>$

with "com.scur.engine.system.proxy.ip"/>$ having been replaced by "com.scur.engine.system"/>$.yourdomain.local.

In human readable format, this could be, for example

http://mwgappl.yourdomain.local:9090

where mwgappl is the host name of an appliance that Web Gateway runs on.

Changing the authentication method

By default, the method used for transparent modes to evaluate credentials is comparing them to the information stored in the internal user database.

To change this authentication method (authentication back-end), you need to configure the settings that appear next to the Authentication.Authenticate property in the Authenticate user against user database rule of the Authentication Server rule set.

Under Authentication method, a list of authentication methods is provided to let you select a method that is better suited to the needs of your network, for example, LDAP or NTLM.

Enabling the ideal conditions rule

The Revalidate session under ideal conditions rule in the Check for Valid Authentication Session rule set lets a user authenticate again under "ideal" conditions, which means authentication will not be asked for at a time when the session has already expired.

In more detail, these conditions are by default:

  • The remaining session time is less than 400 seconds.
  • The network protocol is HTTP.
  • The request that the user sends is a GET request.

Enabling this rule avoids a situation like the following:

  1. A user sends a request from a client of Web Gateway and authenticates (600 seconds are allowed for the session time).
  2. The user wants to send a ticket to the help desk and begins filling out a data form (300 seconds are used up).
  3. The user needs more information to fill out the form and browses the web for this information, which lets some GET requests be received on Web Gateway (200 more seconds are used up).
  4. The user completes the data form and submits it, which lets a POST request be received on Web Gateway
  5. (200 more seconds elapse, session time expires after the first 100 seconds).
  6. As the session time has expired, the user is asked to authenticate again before the POST request is processed. However, due to the session expiration, all filled-out data is lost.

If the ideal conditions rule is enabled, the user is already asked when browsing for information at step 3 to authenticate again, which leaves enough time to complete the form and submit it.

Increasing the session TTL

You can increase the allowed time for an authentication session, for example, from the default 600 seconds (10 minutes) to an hour.

You can also modify the time condition in the criteria of the Revalidate session under ideal conditions rule, for example, by increasing it from 400 to 600 seconds.

This way, the rule will ask a user, upon receiving a GET request, to authenticate when session expiration is still 10 minutes away.

 

  • Was this article helpful?