Authentication Login Options

Use Popup with Authentication:

The mechanism used by Protex to maintain a user's authentication status requires a browser window to be open at all times*. This option allows a site to choose how this window is created.

The default method is to use what is known as a 'Popup' window. Just to restate, this window should not be closed by the user: if it is, a re-login may be required (see next item) and it will certainly reappear after a couple of minutes.

Some schools, however, block popups either via a Group Policy setting or various browser plug-ins. Even if popups are blocked generally it may be possible to allow them from the Protex server centrally using a Group Policy. But not in all cases. If you are not able to unblock popups then by setting this item to no a non popup version of the authentication mechanism can be used. The 'non popup' version does require this extra click from the user but the underlying mechanism is the same and it is important to note that, as before, a new window is generated which must be kept open: if it is closed a re-login will be required after a couple of minutes.

Note that even if you do not block popups you may prefer this scheme - please feel free to choose whichever you like best.

*One reason for the Login window is to reduce the load placed on the Protex server and local network by the NTLM protocol. AD requries every TCP/IP connection to be separately authenticated. Protex will use persistent connections with AD but even so, on a busy page with lots of objects, this can mean that perhaps 20 connections must be opened and authenticated by the Protex server. Persistent connections time out after a short time (between 10-15 seconds) so that in many cases when a user wishes to open a new web-page all the existing connections will be closed and another set will need to be opened and authenticated. Protex avoids this connection issue by putting in place a separate mechanism which requires only a single NTLM authentication every five minutes. Other reasons for this Login window are related to existing and planned facilities (e.g. using timebands) which require this more flexible approach to authentication.

Enable automatic re-login:

If popups are enabled it is possible to enable (yes) or disable (no) automatic re-login. What this does is allow a user to be automatically logged back into the Protex system if the popup window has been closed by the user. There are both advantages and disadvantages to this option. If enabled then if a user closes the popup it will reappear but will not prompt the user to log back in again. This can be an advantage but, on the other hand, it does not train the user not to close the popup and its reappearance may appear to be just an annoyance.

With this option disabled when the popup reappears the user is prompted to login again. The possible advantage to this is that the the user will soon learn not to close the window.

The choice is yours - do whichever seems best for your users.

Note that automatic re-login is NOT available when popups are disabled.

Authentication Method:

When using AD authentication there are two "methods" that can be be used. Redirect to Auth forces user authentication before browsing to any webiste via the Protex server is allowed. With Login on Demand authentication is required only when the user tries to access a site which the default profile blocks. See below for more details.

Redirect to Auth:

This is the usual behaviour, At the very first access to a web page via the Protex server (in most cases this will mean the first external web site visited) the request will be intercepted and the user redirected to an authentication page. Once the user has provided their log in credentials they are assigned the appropriate filter profile and the page they originally requested is returned to the user. Some computer/browser combinations provide the user's network login details transparently so they will not need to manually enter their credentials.

Login on Demand (LoD):

With LoD user authentication only takes place if they browse to a site which the Default Profile would block. This provides the ability to offer a default level of filtering to “unknown” devices and/or users whilst allowing known users to authenticate in order to get their appropriate filter profile which may allow greater access. For example, a sixth former could browse the internet from their own iPad using the default (perhaps the Primary) profile but when a page is blocked they have the option to log in and thus enable their SixthForm filter profile to access it.

As another example, in some cases (ususally Infant or Primary classes) staff want their pupils to be able to browse sites on the Internet without the added complication of having to log in. With LoD set in this case users will, initially, access the internet with the system default profile and are not required to log in. If at some point a page is blocked then the block page provides a Login button. If this is clicked they go through the usual log in process and are assigned their correct profile. If this new profile allows access to the previously denied page then it is sent to the user's browser in the ususal way and the now logged in user continues to use the new profile.

The Login on Demand feature requires the user to attempt access to a blocked URL via the http protocol only and will not work via https. It is expected that the new Landing Page feature will be a better option for BYOD.

Save Changes:

Click to save any changes made.

Cancel Changes:

Click to cancel any changes made and restore the screen to the last saved state.