Implementing proxy authentication
search cancel

Implementing proxy authentication

book

Article ID: 166439

calendar_today

Updated On:

Products

ProxySG Software - SGOS

Issue/Introduction

You want to implement proxy authentication.

Resolution

Adding authentication to the proxy's policy can bring many benefits. Logs will show usernames instead of just IP addresses, and user/group rules can be created as well. This article provides an overview of what is required to authenticate users and the different ways of doing it.

The first step to any authentication implementation is knowing how the proxy is deployed. 

There are two types of proxy implementation:

  • Explicit, which includes manual browser configuration (or group policies) and Proxy Auto Configuration (PAC) files
  • Transparent, which includes inline, Web Cache Communication Protocol (WCCP), and Layer-4 redirection

You must know which type of proxy deployment you have in order to implement an appropriate authentication method. 

Explicit Proxy

Of the two types of proxy implementation, authenticating for explicit proxies is simpler. Most browsers know how to handle proxy authentication, and HTTPS requests have a clear-text "Connect" request made to the proxy, which is easy to authenticate. In an explicit implementation, the proxy sends an HTTP 407 status (Proxy authentication required) for HTTP and HTTPS requests.

How it works (for IWA):

  1. Client sends the original request, e.g., GET www.google.com.
  2. Proxy responds with an HTTP 407 status (Proxy authentication required).
  3. Client returns the original GET request with the correct credentials.
  4. Proxy forwards the request.

Requirements for explicit proxies:

There are no special requirements for HTTPS.

The preferred authentication mode for explicit is "Proxy". For more information on authentication modes, see Article ID: 166803.

Transparent Proxy

Of the two types of proxy implementation, authenticating for transparent proxies is more complex. The proxy cannot send an HTTP 407 status because the browser is not aware that it is going through a proxy. For authentication to work in a transparent implementation, redirection must occur. The virtual URL, which is configured as part of the realm, is used for redirection.

How it works (for IWA):

  1. Client sends the original request.  
  2. Proxy redirects to the virtual URL.
  3. Client sends the request to the virtual URL.
  4. Proxy responds with an HTTP 401 status (Unauthorized).
  5. Client sends credentials.
  6. Proxy validates the credentials, sends a redirect back to the original URL, and includes a set-cookie header (if the surrogate is a cookie).
  7. Client makes the request to the original and includes the authentication cookie.

For this to work, the virtual URL has to be a simple hostname (e.g., http://proxysg), not a hostname and a domain (e.g., http://proxysg.bluecoat.com) so that the browser can recognize the virtual URL as part of the intranet and not the internet. Internet Explorer does not blindly send credentials to the internet zone, but it does for the intranet zone.

The preferred authentication mode for transparent is "Origin cookie redirect". For more information on authentication modes, see Article ID: 166803.

 Requirements for transparent proxies:

  • An authentication realm.
  • A web authentication layer and the necessary authentication rule.
  • A virtual URL that is a single hostname (e.g., http://proxsg).  For more information on setting up a virtual URL, see Article ID: 167387.)
  • An "A" record in your internal DNS server that points the hostname specified in the virtual URL to the proxy's IP address.

If you intercept port 443 and want to authenticate HTTPS, you also require:

  • An SSL interception license, laye,r and rule.
  • A service created on port X of type "HTTPS Reverse Proxy".  It cannot be a known port such as 443; Port 4433 is a good choice.
  • A virtual URL that is HTTPS (e.g., https://proxysg:4433; the same port created in the step above).

Authentication Realm

 The realm, coupled with the authentication layer/rule, dictates the type of authentication the proxy attempts to use and the method used to determine the username.

Here is an overview of the most common realm types and how they work.

IWA (Integrated Windows Authentication)

IWA is the most common type of authentication because of its accuracy. With IWA, the proxy challenges the browser to provide credentials. Most browsers transparently provide the Windows Challenge/Response (NTLM) credentials used during login (no password is transferred--only the username and NTLM information).

The biggest advantage of IWA is that challenging the browser to provide credentials is the best way to make sure that the session was really opened by that user. The drawbackks of IWA are a slight increase in network traffic and the fact that some browsers or user-agents don't know how to use NTLM authentication. When such a browser is challenged, it prompts the user for a username and password.

Requires BCAAA agent: YES
NOTE: If IWA Direct is used, BCAAA agent is not required.
Supports group verification: YES
Supports user-transparent authentication: YES
Authentication type: Browser challenge

For instructions on implementing IWA authentication with the BCAAA agent, see Article ID: 166892

Windows Single Sign-On (SSO)

Windows SSO works without challenging the browser for credentials, which eliminates possible user-agent problems. Windows SSO has two user-configurable methods of authenticating:

  • Domain query, which checks against the domain which user is currently logged on using the IP seen in the request.
  • Client query, which does a registry check on the workstation itself to determine the user name currently logged on. The server on which the BCAAA agent is installed must have the necessary rights to make such a registry check.

Windows SSO on its own cannot verify group membership; it can only determine a user name from an IP address. To create group rules with Windows SSO, LDAP also needs to be used for authorization. With LDAP in place, Windows SSO checks the username, and via LDAP, makes the group verification against the username.

Requires BCAAA agent: YES
Supports group verification: NO (requires LDAP)
Supports user-transparent authentication: YES
Authentication type: Background check

For instructions on implementing Windows SSO authentication, see Article ID: 166901

LDAP

Using LDAP is sometimes necessary, although it is not a very user-friendly way to do authentication. LDAP does not work in the background; it prompts the user for credentials. LDAP does not require an agent installation.

Requires BCAAA agent: NO
Supports group verification: YES
Supports user-transparent authentication: NO
Authentication type: User prompt

For instructions on  implementing  LDAP authentication, see Article ID: 166904

 

Radius

Radius is generally only used when one-time passwords are in place.

Requires BCAAA agent: NO
Supports group verification: YES
Supports user-transparent authentication: NO
Authentication type: User prompt
 

Powered by Wolken Software