Secure proxy gateways – authenticate to protect

Home / News / Secure proxy gateways – authenticate to protect

Authentication allows a secure Internet gateway to recognize which corporate user is getting access, whether to grant such access, and whether or not to “bypass” the connection. It is also naturally related to its authorization – while proving his identity, the user at the same time confirms the level of security policies assigned to him by the system administrator.

Why is it important?

By managing users through an AD directory service – we can control two things – Internet access from their account (an account other than those registered in AD or rules will be rejected by the proxy) and the aforementioned level of security policies.What authentication methods are supported?Typically, Web Security solutions support several methods of user authentication – in order to “release them” to the Internet. The most popular methods are:

  1. Integrated Windows Authentication – (Kerberos from SPNEGO to NTLM) – Integrated Windows Authentication (IWA) is a reliable and most popular method of authenticating users belonging to trusted Windows domains. Kerberos is a network authentication protocol for client / server applications, and SPNEGO provides a Kerberos extension mechanism to web applications using the standard HTTP protocol. If your users are using Windows, IWA authentication is often the preferred method. However, this requires that:
  • Users must be connected to the domain.
  • Client browsers designate the Internet Gateway’s Fully Qualified Domain Name (FQDN) as either the intranet site or the trusted site.
  • For explicit proxy deployments, browsers must specify the FQDN.

  1. NTLM Authentication (NTLMSSP) – Uses the NTLM (NT LAN Manager) authentication protocol as a method of ensuring that users are authenticated on a Windows network before accessing the Internet. It is currently being displaced as the so-called Legacy solution via IWA authentication. When we authenticate via NTLM:
  • The proxy server questions users who request content to validate their credentials.
  • The proxy then sends a proof of the user’s credentials directly to a Windows domain controller for verification.
  • If the credentials are valid, the proxy serves the requested content and stores the credentials in an NTLM cache for future use. If the credentials are incorrect, the proxy sends an authentication failure message.

The main disadvantage of NTLM authentication is the need to periodically “poll” the AD server and that not all browsers support NTLM.

  1. LDAP Authentication – a protocol for using directory services, based on the X.500 standard (for example, a set of network standards covering directory services). Process:
  • The secure proxy acts as an LDAP client and directly “asks” users who request the content for a username and password.
  • After receiving the username and password, the proxy contacts the LDAP server to verify that the credentials are correct.
  • If the LDAP server accepts the user name and password, the proxy server provides the requested content to the client and stores the user name and password in the credential cache. If the LDAP server rejects the username and password, the user’s browser will display a message indicating that authentication has failed and again ask for the username and password.
  • Future authentication requests for this user are handled from the cache until the cache entry expires (expiration time value). The administrator can define the value of the expiry time according to the level of sensitivity – of the security strategy and … users.

Note that by default, LDAP traffic is sent unsecured. You can make LDAP traffic confidential and secure by using Secure Sockets Layer (SSL) / Transport Layer Security (TLS) technology. LDAP over SSL (LDAPS) can be enabled by installing a properly formatted Microsoft or third-party certificate (CA) certificate.

  1. RADIUS Authentication – Remote Authentication Dial In User Service – a service of remote authentication of users who dial into the system (through the “dial-up” service). Process:
  • The proxy acts as a RADIUS client and directly “asks” users who request content for a username and password.
  • After receiving the username and password, the gateway contacts the RADIUS server to verify that the credentials are correct.
  • If the RADIUS server accepts the username and password, the proxy gives the client the requested content and stores the username and password in the RADIUS cache. If the RADIUS server rejects the username and password, the user’s browser displays a message stating that authorization has failed and again prompts for the username and password.

Authentication of AD users is one thing … but what if we support multiple domains?

A secure web proxy should also support combinations of Integrated Windows Authentication (IWA), Legacy NTLM, and LDAP using rule-based authentication – Rule-Based Authentication – is an ordered list of authentication rules. As the request is processed, the list is shifted from top to bottom and the first match is applied. The key parameters for rule-based authentication are:

  1. Rules on how to match the client with:
  • IP address.
  • The incoming proxy port (in explicit proxy mode only).
  • User-Agent values ​​(User-Agent request header to determine if user authentication will be performed. This is useful when you want to authenticate users with a known set of client applications, usually browsers, and allow other applications, often a set of applications that do not support Authentication Rules can also specify IP addresses and, if Content Gateway is an explicit proxy server, the incoming proxy port.
  • Combinations of the above.

  1. Information about a domain or ordered list of domains for authentication. For the list, the first successful authentication is remembered and used in subsequent authentications for that user.
The key use cases are:

Multiple domain networks mentioned. Here, rule-based authentication supports multiple networks where domains do not share a trust relationship and therefore require each domain member to be authenticated by a domain controller in their domain. In this environment, rules are created that define:Domain members (untrusted) – by IP address or proxy portThe sphere (domain) they belong to

Authentication when domain membership is unknown: Some organizations may not always know which domain a user belongs to. For example, this can happen when organizations acquire new businesses and directory services are not mapped or consolidated. The problem of unknown domain membership can be solved with rule-based authentication by creating a rule for lists or ranges of IP addresses that specifies an ordered list of domains against which to try to authenticate. The first successful authentication is remembered and used for later authentications. If authentication fails or the browser times out, authentication is not performed.

Authentication based on User-Agent value: You can specify one or more User-Agent values ​​in an authentication rule. This is often a list of browsers. When User-Agent matches a rule, authentication is performed against the specified domains. If the User-Agent value does not match any rule and none of the rules match the other values, authentication is not performed (it is always true for rule-based authentication; if neither rule matches, then authentication is not performed).For example – an organization with one domain wants to authenticate requests from 2 popular web browsers (e.g. Chrome and Firefox). They also want to bypass authentication for web applications that don’t support authentication.

However, remember not to complicate the deployment unnecessarily – if you don’t need rules, don’t use rule-based authentication. Implementing a single authentication method should provide the best performance.

To sum up..

Authentication allows you to configure the authentication method used by the proxy. This determines how client computers are checked when accessing the Internet. Following the principle of “Know Yourself First, Know Your Opponent” – it is worth spending some planning on ensuring optimal authentication. Proxy authentication must be turned on to create new policies for users or groups. By default, proxy authentication is disabled. When proxy authentication is disabled, we are doomed to introduce rules that are valid only for individual or ranges of IP.



Related articles

Please be advised that our website is using cookies for marketing, statistical and functional reasons. In order to optimize the content on our website and to adapt them to your individual needs, we use informations saved using cookies on users’ end devices. Cookies can be controlled by the user through the settings of their web browser. By contiuning to use our website without changing your web browser settings, you are accepting the use of cookies.