SGOS provides policy control over the operation of the authentication subsystem through the content policy language (CPL) property authenticate.mode(). This article describes how to use authenticate.mode(), and provides guidance on when to use each mode.
There are 13 authentication modes:
- auto (proof of concept only)
Set the authentication mode
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 eol123
- In the Management Console, launch the VPM.
- Navigate to Policy > Add Web Authentication Layer.
- Click OK.
- Right-click in the Action cell.
- In the menu that appears, click Set.
- Click New.
- Click Authenticate.
- (Optional) Change the name of the rule.
- Select the realm.
- Select the mode.
- Click OK.
- Select the Web Authentication Layer object you just created.
- Click OK.
- Navigate to Policy > Add Web Access Layer.
- Right-click in the Action cell.
- In the menu that appears, click Allow.
- Click OK.
- Navigate to File > Install Policy.
Authentication modes explained
Authentication modes are explained in detail in the following guides:
- SGOS Administration Guide for SGOS versions 5.5 and later
- SGOS Configuration and Management Guide (CMG) for SGOS versions 5.4 and earlier
See Symantec Product Documentation
The following information was taken from the SGOS 6.5 Administration Guide. Please check the documentation for any updates on authentication modes.
- Auto: The default (should be used only in POC); 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 the 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 forwarding 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.
- 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.
- 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 surrogate credentials if the client is known not to support cookies.
Rules of thumb using authentication modes:
- To use SSL for authentication in a forward proxy, you must use origin-redirect challenges; origin-cookie-redirect is best.
- 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.
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 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.