Offloading HTTP authentication & authorization

Users : Offloading HTTP authentication & authorization

If a web site does not support RFC 2617 HTTP authentication on its own, nor does it provide HTML form-based authentication, you can use a FortiWeb appliance to authenticate HTTP/HTTPS clients before they are permitted to access a web page.


	User authentication is not supported in all operation modes. See “Supported features in each operation mode”.

Authentication can use either:

• locally-defined accounts

• remotely-defined accounts whose credentials are confirmed with the authentication server via LDAP queries, RADIUS queries, and/or NTLM queries

Based upon the:

• end-user’s confirmed identity

• URL she or he is requesting

FortiWeb then applies rules for that account to determine whether or not to authorize each of the user’s HTTP/HTTPS requests.

HTTP-based authentication provided by your FortiWeb can be used in conjunction with a web site that already has authentication. However, it is usually used as a substitute for a web site that lacks it, or where you have disabled it in order to offload it to the FortiWeb for performance reasons.


	Some compliance schemes, including PCI DSS, require that each person have sole access to his or her account, and that that account be restricted from sensitive data such as cardholder information unless it has a business need-to-know. Be aware of such requirements before you begin. This can impact the number of accounts that you must create, as well as the number and scope of authorization rules. Violations can be expensive in terms of higher processing fees, being barred from payment transactions, and, in case of a security breach, penalties of up to $500,000 per non-compliance.

To configure and activate end-user accounts


	Alternatively or additionally, you can require the end-user to present a personal certificate in order to securely authenticate. See “How to apply PKI client authentication (personal certificates)”.

1. Define user accounts in either or both of the following ways:

• If you want to define end-user accounts on the FortiWeb, create a user name and password record for each user. See “Configuring local end-user accounts”.

• If end-user account credentials are already defined on a remote authentication server, configure a query to that server. See “Configuring LDAP queries”, “Configuring RADIUS queries”, or “Configuring NTLM queries”.

2. Group accounts and queries to create user groups. See “Grouping users”.

3. Configure authorization rules for each user group. See “Applying user groups to an authorization realm”.

4. Group authorization rules into an authorization policy. See “Grouping authorization rules”.

5. Select the authorization policy in an inline protection profile. See “Configuring a protection profile for inline topologies”

6. Select the inline protection profile in a server policy. See “Configuring a server policy”.

When you have configured HTTP authentication

1. If the client’s initial request does not already include an Authorization: field in its HTTP header, the FortiWeb appliance replies with an HTTP 401 Authorization Required response. The response includes a WWW-Authenticate: field in the HTTP header that indicates which style of authentication to use (basic, digest, or NTLM) and the name of the realm (usually the name, such as “Restricted Area”, of a set of URLs that can be accessed using the same set of credentials).

2. The browser then prompts its user to enter a user name and password. (The prompt may include the name of the realm, in order to indicate to the user which login is valid.) The browser includes the user-entered info in the Authorization: field of the HTTP header when repeating its request.

Figure 41: An HTTP authentication prompt in the Google Chrome browser

Valid user name formats vary by the authentication server. For example:

• For a local user, enter a user name in the format username.

• For LDAP authentication, enter a user name in the format required by the directory’s schema, which varies but could be a user name in the format username or an email address such as username@example.com.

• For NTLM authentication, enter a user name in the format DOMAIN/username.

3. The FortiWeb appliance compares the supplied credentials to:

• the locally defined set of user accounts

• a set of user objects in a Lightweight Directory Access Protocol (LDAP) directory

• a set of user objects on a Remote Authentication and Dial-in User Service (RADIUS) server

• a set of user accounts on an NT LAN Manager (NTLM) server

4. If the client authenticates successfully, the FortiWeb appliance forwards the original request to the server.

If the client does not authenticate successfully, the FortiWeb appliance repeats its HTTP 401 Authorization Required response to the client, asking again for valid credentials.

5. Once the client has authenticated with the FortiWeb appliance, if FortiWeb applies no other restrictions and the URL is found, it returns the web server’s reply to the client.

If the client’s browser is configured to do so, it can cache the realm along with the supplied credentials, automatically re-supplying the user name and password for each request with a matching realm. This provides convenience to the user; otherwise, the user would have to re-enter a user name and password for every request.


	Advise users to clear their cache and close their browser after an authenticated session. HTTP itself is stateless, and there is no way to actively log out. HTTP authentication causes cached credentials, which persist until the cache is cleared either manually, by the user, or automatically, when closing the browser window or tab. Failure to clear the cache could allow unauthorized persons with access to the user’s computer to access the web site using their credentials.


	Clear text HTTP authentication is not secure. All user names and data (and, depending on the authentication style, passwords) are sent in clear text. If you require encryption and other security features in addition to authorization, use HTTP authentication with SSL/TLS (i.e. HTTPS) and disable HTTP. See HTTP Service and HTTPS Service.