This article provides an overview of all the authentication methods with descriptions for Bluecoat appliances.
Auto
The default; the mode is automatically selected, based on the request. Auto can choose any of proxy, origin, origin-ip, or origin-cookie-redirect, depending on the kind of connection (explicit or transparent) and the transparent authentication cookie configuration.
Proxy
The ProxySG uses an explicit proxy challenge. No surrogate credentials are used. This is the typical mode for an authenticating explicit proxy. In some situations proxy challenges do not work; origin challenges are then issued.
If you have many requests consulting the back-end authentication authority (such as LDAP, RADIUS, or the BCAAA service), you can configure the ProxySG (and possibly the client) to use persistent connections. This dramatically reduces load on the back-end authentication authority and improves the all-around performance of the network.
Proxy-IP
The ProxySG uses an explicit proxy challenge and the client’s IP address as a surrogate credential. Proxy-IP specifies an insecure forward proxy, possibly suitable for LANs of single-user workstations. In some situations proxy challenges do not work; origin challenges are then issued.
Origin
The ProxySG acts like an OCS and issues OCS challenges. The authenticated connection serves as the surrogate credential.
Origin-IP
The ProxySG acts like an OCS and issues OCS challenges. The client IP address is used as a surrogate credential. Origin-IP is used to support IWA authentication to the upstream device when the client cannot handle cookie credentials. This mode is primarily used for automatic downgrading, but it can be selected for specific situations.
Origin-Cookie
The ProxySG acts like an origin server and issues origin server challenges. A cookie is used as the surrogate credential. Origin-cookie is used in forward proxies to support pass-through authentication more securely than origin-ip if the client understands cookies. Only the HTTP and HTTPS protocols support cookies; other protocols are automatically downgraded to origin-ip.
This mode could also be used in reverse proxy situations if impersonation (where the proxy uses the user credentials to connect to another computer and access content that the user is authorized to see) is not possible and the origin server requires authentication.
Origin-Cookie-Redirect
The client is redirected to a virtual URL to be authenticated, and cookies are used as the surrogate credential. The ProxySG does not support origin-redirects with the CONNECT method. For forward proxies, only origin-*-redirect modes are supported for Kerberos/IWA authentication. (Any other mode uses NTLM authentication).
NOTE: During cookie-based authentication, the redirect request to strip the authentication cookie from the URL is logged as a 307 (or 302) TCP_DENIED.
Origin-IP-Redirect
The client is redirected to a virtual URL to be authenticated, and the client IP address is used as a surrogate credential. The ProxySG does not support origin-redirects with the CONNECT method. For forward proxies, only origin-*-redirect modes are supported for Kerberos/IWA authentication. (Any other mode uses NTLM authentication.)
SG2
The mode is selected automatically, based on the request, and uses the SGOS 2.x-defined rules.
Form-IP
A form is presented to collect the user’s credentials. The form is presented whenever the user’s credential cache entry expires.
Form-Cookie
A form is presented to collect the user’s credentials. The cookies are set on the OCS domain only, and the user is presented with the form for each new domain. This mode is most useful in reverse proxy scenarios where there are a limited number of domains.
Form-Cookie-Redirect
A form is presented to collect the user’s credentials. The user is redirected to the authentication virtual URL before the form is presented. The authentication cookie is set on both the virtual URL and the OCS domain. The user is only challenged when the credential cache entry expires.
Form-IP-Redirect
This is similar to form-ip except that the user is redirected to the authentication virtual URL before the form is presented.