Authentication for Transparent Modes

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 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.