Section D: Using CPL with Forms-Based Authentication
To use forms-based authentication, you must create policies that enable it and also control which form is used in which situations. A form must exist before it can be referenced in policy.
❐ Which form to use during authentication is specified in policy using one of the CPL conditions authenticate.form(form_name),
authenticate.new_pin_form(form_name), or authenticate.query_form (form_name).
These conditions override the use of the initial forms for the cases where a new pin form needs to be displayed or a query form needs to be displayed. All three of the conditions verify that the form name has the correct type.
❐ Using the authentication.mode( ) property selects a combination of challenge type and surrogate credentials. The authentication.mode( ) property offers several options specifically for forms-based authentication: • Form-IP—The user’s IP address is used as a surrogate credential. The form
is presented whenever the user’s credential cache entry expires.
• Form-Cookie—Cookies are used as surrogate 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—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.
❐ If you authenticate users who have third-party cookies explicitly disabled, you can use the authenticate.use_url_cookie( ) property.
❐ Since the authentication.mode( ) property is defined as a form mode (above) in policy, you do not need to adjust the default authenticate mode through the CLI.
Note: Each of these conditions can be used with the form authentication modes only. If no form is specified, the form defaults to the CPL condition for that form. That is, if no name is specified for authenticate.form(form_name), the default is authentication_form; if no name is specified for
authenticate.new_pin_form(form_name), the default is authenticate.new_pin_form, and if no name is specified for authenticate.query_form(form_name), the default is
❐ Using the authenticate.redirect_stored_requests(yes|no) action allows granularity in policy over the global allow redirect config option.
For information on using these CPL conditions and properties, refer to Volume 10:
Content Policy Language Guide.
Tips
❐ If the user is supposed to be challenged with a form on a request for an image or video, the ProxySG returns a 403 error page instead of the form. If the reason for the challenge is that the user's credentials have expired and the object is from the same domain as the container page, then reloading the container page results in the user receiving the authentication form and being able to authenticate. However, if the client browser loads the container page using an existing authenticated connection, the user might still not receive the authentication form.
Closing and reopening the browser should fix the issue. Requesting a different site might also cause the browser to open a new connection and the user is returned the authentication form.
If the container page and embedded objects have a different domain though and the authentication mode is form-cookie, reloading or closing and reopening the browser might not fix the issue, as the user is never returned a cookie for the domain the object belongs to. In these scenarios, Blue Coat recommends that policy be written to either bypass authentication for that domain or to use a different authentication mode such as form-cookie-redirect for that domain.
❐ Forms-based authentication works with HTTP browsers only.
❐ Because forms only support Basic authentication, authentication-form
exceptions cannot be used with a Certificate realm. If a form is in use and the authentication realm is or a Certificate realm, you receive a configuration error.
❐ User credentials are sent in plain text. However, they can be sent securely using SSL if the virtual URL is HTTPS.
❐ Because not all user requests support forms (such as WebDAV and streaming), create policy to bypass authentication or use a different authentication mode with the same realm for those requests.
This chapter discusses Integrated Windows Authentication (IWA), which is an authentication mechanism available on Windows networks. (The name of the realm has been changed from NTLM to IWA.)
Topics in this Chapter
This chapter includes information about the following topics:
❐ "About IWA" on page 133
❐ "How Blue Coat Works with IWA" on page 133
❐ "Creating an IWA Realm" on page 134
❐ "IWA Servers" on page 134
❐ "Defining IWA Realm General Properties" on page 136
❐ "Creating the CPL" on page 139
❐ "Notes" on page 140
About IWA
IWA is a Microsoft-proprietary authentication suite that allows Windows clients (running on Windows 2000 and higher) to automatically choose between using Kerberos and NTLM authentication challenge/response, as appropriate. When an IWA realm is used and a resource is requested by the client from the ProxySG, the appliance contacts the client's domain account to verify the client's identity and request an access token. The access token is generated by the domain controller (in case of NTLM authentication) or a Kerberos server (in the case of Kerberos authentication) and passed to (and if valid, accepted by) the ProxySG.
Refer to the Microsoft Web site for detailed information about the IWA protocol.