A number of general permissions can be set for each group in the Permisions & Limits subsection of the Web Proxy module. These settings will also be inherited by all the descendent groups, unless explicitly overridden. If you need to override the inherited settings, untick the Inherit box of the setting and adjust it as appropriate.
If the filtering is simply being used to prevent trusted users from accidentally stumbling across inappropriate content, it can be useful to allow those users to override a block if they are sure that the website they are visiting is ok. When a user is blocked, if they are in a group with this setting ticked they will be given the option to temporarily override the block and continue to the website.
Users who are in a group that has this option ticked will not be restricted by any web filtering or bandwidth limits at all, irrespective of any other settings.
By intercepting HTTPS traffic, the filter to decrypt, analyse and log encrypted traffic. This option allows you to find a balance between safety and intrusiveness:
- Active interception - Traffic may be fully decrypted. The filter will be able to examine the whole URI and content in order to categorise the request. Logs will contain full data, including the whole URI, content type, etc. Client devices need to have your unique Opendium interception certificate installed.
- Passive inspection - The SSL handshake may be decoded but traffic will not be decrypted. The filtering capabilities will be reduced - only the host name part of the URI will be used for categorisation and no content can be examined. The logs will only contain the host name part of the URI. Client devices do not need the Opendium certificate installed.
- Disabled - No examination of the encrypted traffic is done. The filtering capabilities will be extremely limited as the only information available to the filter is the host name part of the URI for non-transparently proxied traffic. Logs will contain the host name part of the URI if it is available, or just the IP address of the web server.
Note that by default, banking websites are excluded from active interception. We recommend that active interception is enabled for students. It is often convenient to use passive inspection for guest devices.
Different types of device require different techniques in order to unobtrusively associate the web requests with specific users. This option allows you to pick a suitable profile. The Automatic setting provides a reasonable default that works reasonably well in most situations, but setting a more specific profile to each part of your network helps provide the best compatibility with the devices.
Since many of these user identification modes rely on caching user credentials for a period of time, the lease expiry on the DHCP server should be no shorter than 48 hours.
- Automatic [NOT RECOMMENDED] - this is an "all round" mode that works in most situations. However, it has a number of problems, so it is preferable to divide your network up so that a more appropriate setting can be used for networks of each type of device. A combination of HTTP proxy authentication, captive portal authentication, WISPr and RADIUS accounting will be used.
- Automatic 2 [NOT RECOMMENDED] - similar to Automatic mode, except that traffic through the transparent proxy will not be authenticated. This mode is not recommended.
- Workstation - for networks of workstations which accept logins from several non-concurrent users. A combination of HTTP proxy authentication and RADIUS accounting will be used. Devices must be configured to use the proxy. Transparently proxied requests will be denied until after an authenticated proxy request has been made.
- Single user devices - for networks of devices whereby each device is only used by a single user. For example, wifi networks of personal devices such as phones, tablets, etc. A combination of captive portal authentication, WISPr and RADIUS accounting will be used. It is recommended that you also configure your wifi controller to send RADIUS accounting data to Web Gateway / UTM.
- Multiuser servers - for networks of servers whereby each server is expected to be used by multiple concurrent users. HTTP proxy authentication will be used exclusively. When HTTP proxy authentication is not possible, users will not be identified.
- RADIUS - for networks that provide login and logout notifications through RADIUS accounting, such as wifi networks using 802.1x / WPA2 Enterprise authentication. Only RADIUS accounting will be used. You must also configure your wifi controller to send RADIUS accounting data to Web Gateway / UTM. This method is also used for the Opendium Chrome browser extension (see below).
- Disabled - users are not identified.
A brief description of the authentication mechanisms which are commonly used:
- HTTP Negotiate proxy authentication (Kerberos / NTLM) - this is the primary method used by workstations that are connected to a Windows domain. It is a single-signon system, so the user only needs to log onto the workstation and never has to authenticate with the proxy separately. It is, in theory, possible to authenticate every web connection individually for maximum accuracy, but in reality some software is not compatible and most user identification modes only authenticate some of the requests and use cached information for the rest.
- HTTP Basic proxy authentication - this also sends authentication information directly to the proxy, but is not a single-signon mechanism. The user will usually see a popup authentication box when they start their web browser, but the browser may save their credentials between sessions.
- 802.1x / WPA2 Enterprise - the device sends login credentials to the wifi access point or ethernet switch when it is connected to the network, and the access point or switch forwards that information onto the Opendium RADIUS accounting server. The proxy needs to perform no further authentication, since it can identify the user based on the information stored in the RADIUS server.
- Captive portal - web requests are redirected to a login page which the user can log in to with their user name and password.
- WISPr - this works like the captive portal, except that the device saves the login credentials the first time the user logs in through the portal, and automatically logs back in each time the device reconnects to the network.
- ChromeOS passthrough authentication - Chromebooks can be configured to log in to an 802.1x wifi network using an "onboarding" user name, and then re-login to the network as the appropriate user once a user has logged into the device. The "onboarding" user should have the walled garden enabled and the ChromeOS Onboarding override applied. It may be advisable to also assign the "onboarding" user to a separate VLAN.
- Chrome extension - schools who use Google Classroom and have no other facilities for providing user identification information to the Opendium server can install the Opendium user identification extension for the Chrome web browser. Whenever the user logs onto Google Classroom, their browser will automatically send their user name to the Opendium system. The Chrome Onboarding override should be applied to the network and the user identification profile set to RADIUS.
The amount a user downloads over the web can be restricted by enabling this setting. Once a user has exceeded the limit, their web requests will be blocked.
This works on a "Leaky Bucket" model: If, for example, a user is allowed to download 500MB per hour, they start with 500MB left in their quota. If they then use 400MB of that over a half hour period, at the end of that time they will have 350MB of their quota left (100MB of the original 500MB, plus the 250MB extra they accumulated over that half hour based on the 500MB/hour limit). As such, a user can actually use up to 1000MB in a single hour, but when averaged over a longer period the limit tends towards the configured 500MB per hour.