Solutions

ProxySG Authentication Modes explained

Solutions ID:    KB2877
Version:    5.0
Status:    Published
Published date:    05/05/2009
Updated:    05/08/2012
 

Problem Description

What do the various authentication modes on the ProxySG mean?

Resolution

SGOS provides policy control over the operation of the authentication subsystem through the content policy language (CPL) property authenticate.mode(). This document shows how to use authenticate.mode(), and gives some guidance on when to use each mode.

There are 13 authentication modes: auto, form-cookie, form-cookie-redirect, form-ip, form-ip-redirect, proxy, proxy-ip, origin, origin-ip, origin-cookie, origin-cookie-redirect, origin-ip-redirect, and sg2.

 

To specify a particular mode for a transaction, set the authenticate.mode() property through the command line interface (CLI) or the Visual Policy Manager (VPM) in the Management Console.

 

Through the CLI:

ProxySG#Inline policy local foo
<proxy>
authenticate.mode(origin) authenticate(ldaprealm)
foo

Through VPM:

  1. In the Management Console, launch the VPM.
  2. Go to Policy > Add Web Authentication Layer.
  3. Click OK.
  4. Right click in the Action cell.
  5. On the menu that appears, select  Set.
  6. Click New.
  7. Click Authenticate.
  8. (Optional) Change the name of the rule.
  9. Select the realm.
  10. Select the mode.
  11. Click OK.
  12. Select the Web Authentication Layer object you just created.
  13. Click OK.
  14. Go to Policy > Add Web Access Layer.
  15. Right click in the Action cell.
  16. On the menu that appears, select Allow.
  17. Click OK.
  18. Go to File > Install Policy.

Explanation of Modes

Each authentication mode is detailed in the SGOS Configuration and Management Guide (CMG) for SGOS versions 5.4 and earlier, and in the SGOS Administration Guide for SGOS versions 5.5 and later.  SGOS documentation for all versions is located at https://bto.bluecoat.com/documentation/pubs/ProxySG.  The following information was taking from the SGOS 5.4 CMG.  Please check the documentation for any updates on authentication modes.

  • 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 in SGOS versions before 5.4.x, only origin-*-redirect modes are supported for Kerberos/IWA authentication.  (Any other mode uses NTLM authentication). After SGOS 5.4.x, Kerberos authentication is supported for explicit deployments also
    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.

IMPORTANT:  The authenticate.mode() setting may be overridden by the SG if it knows that the client cannot support the requested mode.  For example, if the client is known not to support proxy-style authentication, the ProxySG will automatically switch the mode to origin-style.  Similarly, cookie surrogate credentials are downgraded to IP surroage credentials if the client is known not to support cookies. 

Rules of thumb for using authentication modes:

  1. To use SSL for authentication in a forward proxy, you must use origin-redirect challenges; origin-cookie-redirect is best.
  2. For reverse proxy deployments, use origin.  If the origin server also needs to authenticate the user and cannot be modified to use a trusted header, use origin-cookie.

Key Concepts

Two concepts are key to understanding authenticate modes:

  • Challenge type, which specifies the kind of challenge that will be issued to the client

  • Surrogate credentials, which are used to authenticate a transaction other than the "real" credentials.

Even in the absence of surrogate credentials, once a transaction has been authenticated, transactions on the same persistent connection are also considered authenticated.


IP
 Surrogates

IP surrogates are recommended for deployments larger than 1,000 users; however, note the following:

  • Do not use IP surrogate credentials for NATed users or multi-user systems.  The best practice is to make an authentication policy using IP credentials for normal PC users and use non-IP credential for NATed or multi-user systems (such as Citrix, Terminal Server, etc.).
  • The best way to achieve this policy is to have NATed users connect to a TCP port different from other regular PCs.  Alternatively, you can identify these systems by IP address and accompanying subnet.
  • These recommendations apply for Active Directory (AD) authentication using IWA/NTLM or SSO.

 


Rate this Page

Please take a moment to complete this form to help us better serve you.

Did this document help answer your question?
 
 
If you are finished providing feedback, please click the RATE CONTENT button. Otherwise, please add more detail in the following text box and then click RATE CONTENT.
 
 

Your response will be used to improve our document content.

Ask a Question