Offloading HTTP authentication & authorization

If a website 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 or URL she or he is requesting.

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

HTTP-based authentication provided by your FortiWeb can be used in conjunction with a website that already has authentication. However, it is usually used as a substitute for a website 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.

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 website 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.

Configuring local end-user accounts

FortiWeb can use local end-user accounts to authenticate and authorize HTTP requests to protected websites. For details, see Offloading HTTP authentication & authorization.

To configure a local user

1. Go to User > Local User.

To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Auth Users category. For details, see Permissions.

2. Click Create New.

3. Configure these settings:

Setting name Description

Setting name	Description
Name	Type a name that can be referenced in other parts of the configuration, such as `Jane Doe`. Do not use special characters. The maximum length is 63 characters. Note: This is not the user name that the person must provide when logging in to the CLI or web UI.
User Name	Type the user name that the client must provide when logging in, such as `user1`. The maximum length is 63 characters.
Password	Type a password for the user account. The maximum length is 63 characters. Tip: For improved security, the password should be at least eight characters long, be sufficiently complex, and be changed regularly. To check the strength of your password, you can use a utility such as Microsoft’s password strength meter.

Name

Type a name that can be referenced in other parts of the configuration, such as Jane Doe.

Do not use special characters. The maximum length is 63 characters.

Note: This is not the user name that the person must provide when logging in to the CLI or web UI.

User Name

Type the user name that the client must provide when logging in, such as user1.

The maximum length is 63 characters.

Password

Type a password for the user account.

The maximum length is 63 characters.

Tip: For improved security, the password should be at least eight characters long, be sufficiently complex, and be changed regularly. To check the strength of your password, you can use a utility such as Microsoft’s password strength meter.

4. Click OK.

5. To activate the user account, you must indirectly include it in a server policy that governs connections to your web servers. Continue with Grouping users. (For an overview, see To configure and activate end-user accounts.)

Configuring queries for remote end-user accounts

FortiWeb supports multiple query types that you can use to authenticate users with accounts stored on remote servers, rather than with accounts on the FortiWeb itself.

Configuring LDAP queries

FortiWeb can use LDAP queries to authenticate and authorize end-users’ HTTP requests to protected websites. For details, see Offloading HTTP authentication & authorization. FortiWeb can also use LDAP queries to authenticate administrators’ access to the web UI or CLI. For details, see Grouping remote authentication queries and certificates for administrators.

If you use an LDAP query for administrators, separate it from the queries for regular users. Do not combine administrator and user queries into a single entry. Failure to separate queries will allow end-users to have administrative access the FortiWeb web UI and CLI. If administrators are in the same directory but belong to a different group than end-users, you can use Group Authentication to exclude end-users from the administrator LDAP query.

Supported servers may implement the underlying technology and group membership in different ways, such as with OpenLDAP, Microsoft Active Directory, IBM Lotus Domino, and Novell eDirectory. Match the distinguished names (DN) and group membership attributes (Group Type) with your LDAP directory’s schema.

If this query will be used to authenticate administrators, and your LDAP server is slow to answer, you may need to adjust the authentication timeout setting to prevent the query from failing. See the FortiWeb CLI Reference. (For end-user queries, configure Connection Timeout instead.)

To configure an LDAP query

1. Before you configure the query, if it will use a secure connection, you must upload the certificate of the CA that signed the LDAP server’s certificate. For details, see Uploading trusted CA certificates.

2. Go to User > Remote Server and select the LDAP Server tab.

To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Auth Users category. For details, see Permissions.

3. Click Create New.

A dialog appears.

4. Configure these settings:

Setting name	Description
Name	Type a unique name that can be referenced in other parts of the configuration. Do not use special characters. The maximum length is 63 characters. Note: This is the name of the query only, not the administrator or end-user’s account name/login. Administrator account names are defined in Administrator.
Server IP/Domain Name	Type the IP address or domain name of the LDAP server.
Server Port	Type the port number where the LDAP server listens. The default port number varies by your selection in Secure Connection: port 389 is typically used for non-secure connections or for STARTTLS-secured connections, and port 636 is typically used for SSL-secured (LDAPS) connections.
Common Name Identifier	Type the identifier for the common name (CN) attribute (also called the CNID) whose value is the user name. Identifiers vary by your LDAP directory’s schema. This is often `cn` or `uid`. For Active Directory, it is often the attribute `sAMAccountName`. For example, in a default OpenLDAP directory, if a user object is: `uid=hlee,cn=users,dc=example,dc=com` then the CNID is `uid`. For an additional example for Active Directory, see Example for a configuration for AD.
Distinguished Name	Specifies the Base DN from which the LDAP query starts. This DN is the full path in the directory to the user account objects. For example: `ou=People,dc=example,dc=com` or `cn=users,dc=example,dc=com`
Bind Type	Select one of the following LDAP query binding styles: Simple — Bind using the client-supplied password and a bind DN assembled from the Common Name Identifier, Distinguished Name, and the client-supplied user name. Regular — Bind using a bind DN and password that you configure in User DN and Password. This also allows for group authentication. Anonymous — Do not provide a bind DN or password. Instead, perform the query without authenticating. Select this option only if the LDAP directory supports anonymous queries.
User DN	Type the bind DN of an LDAP user account with permissions to query the Distinguished Name. For example: `cn=FortiWebA,dc=example,dc=com` For Active Directory, the UPN (User Principle Name) is often used instead of a bind DN (for example, `user@domain.com`) The maximum length is 255 characters. This field can be optional if your LDAP server does not require the FortiWeb appliance to authenticate when performing queries. This field is not displayed if Bind Type is Anonymous or Simple.
Password	Type the password of the User DN. This field may be optional if your LDAP server does not require the FortiWeb appliance to authenticate when performing queries, and does not appear if Bind Type is Anonymous or Simple.
Filter	Type an LDAP query filter string that filters the query’s results based on any attribute in the record set. For example: `(&(\|(objectClass=user)(objectClass=group)(objectClass=publicFolder)))` This filter improves the speed and efficiency of the queries. For syntax, see an LDAP query filter reference. If you do not want to exclude any accounts from the query, leave this setting blank. The maximum length is 255 characters. This option appears when Bind Typeis Regular.
Group Authentication	Enable to filter the query results, only allowing users to authenticate if they are members of the LDAP group that you define in Group DN. Users that are not members of that group will not be allowed to authenticate. Also configure Group Type and Group DN. This option appears only when Bind Typeis Regular.
Group Type	Indicate the schema of your LDAP directory, either: OpenLDAP — The directory uses a schema where each user object’s group membership is recorded in an attribute named `gidNumber`. This is usually an OpenLDAP directory, or another directory where the object class `inetOrgPerson` or `posixAccount`. Windows-AD — The directory uses a schema where each user object’s group membership is recorded in an attribute named `memberOf`. This is usually a Microsoft Active Directory server. eDirectory — The directory uses a schema where each user object’s group membership is recorded in an attribute named `groupMembership`. This is usually a Novell eDirectory server. Group membership attributes may have different names depending on an LDAP directory schemas. The FortiWeb appliance will use the group membership attribute that matches your directory’s schema when querying the group DN. This option appears only when Bind Type is Regular and Group Authentication is enabled.
Group DN	Type the value of the group membership attribute that query results must have in order to be able to authenticate. The value may vary by your directory’s schema, but may be the distinguished name such as `ou=Groups,dc=example,dc=com` or a group ID (GID) such as 100. This option appears only when Bind Typeis Regular and Group Authentication is enabled. The maximum length is 255 characters.
Secure Connection	Enable to connect to the LDAP servers using an encrypted connection, then select the style of the encryption in Protocol.
Protocol	Select which secure LDAP protocol to use, either LDAPS STARTTLS The option appears only when Secure Connection is enabled.

5. Click OK.

6. If you enabled Secure Connection, upload the certificate of the CA that signed the directory server’s certificate (see Uploading trusted CA certificates).

7. Return to User > Remote Server, select the LDAP User tab, double-click the row of the query, then click the Test LDAP button to verify that FortiWeb can connect to the server, that the query is correctly configured, and that (if binding is enabled) the query bind is successful.

In username, type only the value of the CNID attribute, such as hlee, not the entire DN of the administrator’s account. In password, type the password for the account.

8. If the query is for administrator accounts that you want to allow to access the FortiWeb web UI, select the query in a remote authentication query group (see Grouping remote authentication queries and certificates for administrators).

If the query is for user accounts that you want to allow to authenticate with web servers, to activate the user account, you must indirectly include it in a server policy. Continue with Grouping users. (For an overview, see To configure and activate end-user accounts.)

If the query is for a site publishing rule that offloads authentication for a web application to FortiWeb, you first add it to an authorization server pool. See Adding servers to an authentication server pool.

Example for a configuration for AD

The following sample values are part of an LDP query for a Microsoft Active Directory (AD) domain server.

Setting	Value	Notes
Common Name Identifier	`sAMAccountName`	In most cases, you use the Common Name Identifier `sAMAccountName` as the container. In some cases, `userPrincipalName` is used, especially if there is a domain forest.
Distinguished Name (Base DN)	`OU=CONTAINER, DC=DOMAIN,DC=SUFFIX`	Specifies the Base DN from which the LDAP query starts.
Filter	(&(objectCategory=person) (objectClass=user) (sAMAccountName=*))	If Common Name Identifier is `userPrincipalName`, change `sAMAccountName` to `userPrincipalName`.
User DN	user@domain.com	This example uses the UPN (User Principle Name) instead of a bind DN.

Configuring RADIUS queries

FortiWeb can use RADIUS queries to authenticate and authorize end-users’ HTTP requests (see Offloading HTTP authentication & authorization). FortiWeb can also use RADIUS queries to authenticate administrators’ access to the web UI or CLI (see Grouping remote authentication queries and certificates for administrators).

If you use a RADIUS query for administrators, separate it from the queries for regular users. Do not combine administrator and user queries into a single entry. Failure to separate queries will allow end-users to have administrative access the FortiWeb web UI and CLI.

Remote Authentication and Dial-in User Service (RADIUS) servers provide authentication, authorization, and accounting functions. The FortiWeb authentication feature uses RADIUS user queries to authenticate and authorize HTTP requests. (The HTTP protocol does not support active logouts, and can only passively log out users when their connection times out. Therefore FortiWeb does not fully support RADIUS accounting.) RADIUS authentication with realms (i.e. the person logs in with an account such as admin@example.com) are supported.

To authenticate a user or administrator, the FortiWeb appliance sends the user’s credentials to RADIUS for authentication. If the RADIUS server replies to the query with a signal of successful authentication, the client is successfully authenticated with the FortiWeb appliance. If RADIUS authentication fails or the query returns a negative result, the appliance refuses the connection.

If this query will be used to authenticate administrators, and your RADIUS server is slow to answer, you may need to adjust the authentication timeout setting to prevent the query from failing. See the FortiWeb CLI Reference. (For end-user queries, configure Connection Timeout instead.)

To configure a RADIUS query

1. Before configuring the query, if you will configure a secure connection, you must upload the certificate of the CA that signed the RADIUS server’s certificate. For details, see Uploading trusted CA certificates.

2. Go to User > Remote Server and select the RADIUS Server tab.

To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Auth Users category. For details, see Permissions.

3. Click Create New.

A dialog appears.

4. Configure these settings:

Setting name	Description
Name	Type a unique name that can be referenced in other parts of the configuration. Do not use spaces or special characters. The maximum length is 63 characters. Note: This is the name of the query only, not the administrator or end-user’s account name/login. Administrator account names are defined in Administrator. End-user names are not defined in the configuration; credentials provided by the person during login will be used for the query.
Server IP	Type the IP address of the primary RADIUS server.
Server Port	Type the port number where the RADIUS server listens. The default port number is 1812.
Server Secret	Type the RADIUS server secret key for the primary RADIUS server. The primary server secret key should be a maximum of 16 characters in length.
Secondary Server IP	Type the IP address of the secondary RADIUS server, if applicable.
Secondary Server Port	Type the port number where the RADIUS server listens. The default port number is 1812.
Secondary Server Secret	Type the RADIUS server secret key for the secondary RADIUS server. The secondary server secret key should be a maximum of 16 characters in length.
Authentication Scheme	Select either: Default to authenticate with the default method. The default authentication scheme uses PAP, MS-CHAP-V2, and CHAP, in that order. MS-CHAP-V2, CHAP, MS-CHAP, or PAP, depending on what your RADIUS server requires.
NAS IP	Type the NAS IP address and Called Station ID (for more information about RADIUS Attribute 31, see RFC 2548 Microsoft Vendor-specific RADIUS Attributes). If you do not enter an IP address, the IP address that the FortiWeb appliance uses to communicate with the RADIUS server will be applied.

5. Click OK.

6. Return to User > Remote Server, select the RADIUS Server tab, double-click the row of the query, then click the Test RADIUS button to verify that FortiWeb can connect to the server, and that the query is correctly configured.

7. If the query is for administrator accounts that you want to allow to access the FortiWeb web UI, select the query in a remote authentication query group (see Grouping remote authentication queries and certificates for administrators).

For access profiles, FortiWeb appliances support RFC 2548 Microsoft Vendor-specific RADIUS Attributes. If you do not want to use them, you can configure them locally instead. See Configuring access profiles.

If the query is for user accounts that you want to allow to authenticate with web servers, to activate the user account, you must indirectly include it in a server policy. Continue with Grouping users. (For an overview, see To configure and activate end-user accounts.)

Configuring NTLM queries

NT LAN Manager (NTLM) queries can be made to a Microsoft Windows or Active Directory server that is configured for NTLM authentication. FortiWeb supports both NTLM v1 and NTLM v2.

FortiWeb can use NTLM queries to authenticate and authorize HTTP requests. For more information, see Applying user groups to an authorization realm.

To configure an NTLM query

1. Go to User > Remote Server and select the NTLM Server tab.

To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Auth Users category. For details, see Permissions.

2. Click Create New.

A dialog appears.

3. In Name, type a unique name that can be referenced by other parts of the configuration. This is the name of the query only, not the end-user’s account name/login. Do not use spaces or special characters. The maximum length is 63 characters.

4. For Server IP, type the IP address of the NTLM server to query.

5. For Port, type the TCP port number where the NTLM server listens for queries.

6. Click OK.

7. To activate the user account, you must indirectly include it in a server policy that governs connections to your web servers. Continue with Grouping users. (For an overview, see To configure and activate end-user accounts.)

Adding servers to an authentication server pool

When you configure a site publishing rule that offloads authentication for a web application to FortiWeb, you use an authentication server pool to specify the method and server that FortiWeb uses to authenticate clients.

The pool can contain one or more servers that use either LDAP or RADIUS to authenticate clients. You add LDAP or RADIUS servers to an authentication server pool using the queries that correspond to the servers (see Configuring LDAP queries and Configuring RADIUS queries).

FortiWeb attempts to authenticate clients using the server at the top of the list of pool members, and then continues to the next member down in the list if the authentication is unsuccessful, and so on. You can use the list options to adjust the position of each item in the list.

To configure an authentication server pool

1. Go to Application Delivery > Site Publish > Authentication Server Pool.

2. Click Create New, enter a name for the pool, and then click OK.

3. Click Create New and complete the following settings:

Setting name	Description
Authentication Validation Method	Select whether this pool member uses LDAP or RADIUS to authenticate clients.
LDAP Server or RADIUS Server	Select the name of the authentication query that FortiWeb uses to pass credentials to your authentication server.
RSA SecurID	Select to enable client authentication using a username and a RSA SecurID authentication code only. Users are not required to enter a password. When this option is enabled, the authentication delegation options in the site publish rule are not available. For more information, see RSA SecurID authentication. Alternatively, you can use the default two-factor authentication feature to require users to enter a username, password, and a RSA SecurID authentication code. For more information, see Two-factor authentication.

Setting name

Description

Authentication Validation Method

Select whether this pool member uses LDAP or RADIUS to authenticate clients.

LDAP Server

RADIUS Server

Select the name of the authentication query that FortiWeb uses to pass credentials to your authentication server.

RSA SecurID

Select to enable client authentication using a username and a RSA SecurID authentication code only. Users are not required to enter a password.

When this option is enabled, the authentication delegation options in the site publish rule are not available.

For more information, see RSA SecurID authentication.

Alternatively, you can use the default two-factor authentication feature to require users to enter a username, password, and a RSA SecurID authentication code.

For more information, see Two-factor authentication.

4. Click OK.

5. Add any other additional servers you want in the pool.

6. To use the pool, select it when you configure a site publish rule. For more information, see Offloaded authentication and optional SSO configuration

Configuring a Kerberos Key Distribution Center (KDC)

You can specify a Kerberos Key Distribution Center (KDC) that FortiWeb can use to obtain a Kerberos service ticket for web applications on behalf of clients.

Because FortiWeb determines the KDC to use based on the realm of the web application, you do not have to specify the KDC in the site publish rule.

For more information, see Using Kerberos authentication delegation and Offloaded authentication and optional SSO configuration.

To configure a KDC server

1. Go to User > Remote Server and select the KDC Server tab.

To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Auth Users category. For details, see Permissions.

2. Click Create New and complete the following settings:

Setting name	Description
Name	Enter a name that can be referenced by other parts of the configuration.
Delegated Realm	Enter the domain of the domain controller (DC) that the Key Distribution Center (KDC) belongs to. Typically the UPN (User Principle Name) used for login has the format username@delegated_realm.
Shortname	Enter the shortname for the realm you specified (This is optional). A shortname is an alias of the delegated realm; it can be any set of characters except for symbols "@", "/" and "\". For example, the shortname can include the domain name of the realm that is not fully qualified. With a shortname being configured, the format of UPN can be username@shortname.
Server IP	Enter the IP address of the KDC. In most cases, the KDC is located on the same server as the DC.
Port	Enter the port the KDC uses to listen for requests.

3. Click OK.

Grouping users

To denote which set of people is authorized to request specific URLs when configuring HTTP authentication offloading, you must create user groups.

A user group can include a mixture of local end-user accounts, LDAP queries, RADIUS queries, and NTLM queries. Therefore, on FortiWeb, a user group could be set of accounts, or it could be a set of queries instead.

To configure a user group

1. Before you can configure a user group, you must first configure one or more local end-user accounts or queries to remote authentication servers. See:

Configuring local end-user accounts
Configuring LDAP queries
Configuring RADIUS queries
Configuring NTLM queries

To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Auth Users category. For details, see Permissions.

2. Go to User > User Group > User Group.

3. Click Create New.

A dialog appears.

4. In Name, type a name that can be referenced by other parts of the configuration. Do not use special characters. The maximum length is 63 characters.

5. In Auth Type, select one of the following authentication types:

Basic — Clear text. This is the original and most compatible authentication scheme for HTTP. However, it is also the least secure as it sends the user name and password unencrypted to the server.
Digest — Encrypts the password and thus is more secure than the basic authentication.
NTLM — Uses a proprietary protocol of Microsoft and is considered to be more secure than basic authentication.

6. Click OK.

The Create New button for this item, below its name, will no longer be greyed out, indicating that it has become available.

7. Click Create New.

A dialog appears that enables you to add members to the group.

8. In User Type, select the type of user or user query you want to add to the group. Available options vary with the setting for the group’s Auth Type option.

You can mix user types in the group. However, if the authentication rule’s Auth Type does not support a given user type, all user accounts of that type will be ignored, effectively disabling them.

9. From User Name, select the name of an existing user account, LDAP query, or RADIUS query. Available options vary by your selection in User Type.

10. Click OK.

11. Repeat the previous steps for each user or query that you want to add to the group.

12. Select the user group in an authorization rule (see Applying user groups to an authorization realm).

Applying user groups to an authorization realm

Authentication rules are used by the HTTP authentication policy to define sets of request URLs that will be authorized for each end-user group.

Alternatively, you can configure site publishing, which has the additional advantage of optionally providing SSO for multiple web applications. See Single sign-on (SSO) (site publishing).

To configure an authentication rule

1. Before you can configure an authentication rule set, you must first configure any user groups that you want to include. For details, see Grouping users.

If you want to apply rules only to HTTP requests for a specific real or virtual host, you must first define the web host in a protected host names group. For details, see Defining your protected/allowed HTTP “Host:” header names.

2. Go to Application Delivery > Authentication and select the Authentication Rule tab.

To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see Permissions.

3. Click Create New.

A dialog appears.

4. In Name, type a name that can be referenced by other parts of the configuration. Do not use spaces or special characters. The maximum length is 63 characters.

5. If you want to require that the Host: field of the HTTP request matches a protected host entry in order to match the HTTP authentication rule, do the following:

Enable Host Status.
From Host, select which protected host entry (either a web host name or IP address) the Host: field of the HTTP request must be. The list contains hosts configured in a protected host names group. For details, see Defining your protected/allowed HTTP “Host:” header names.

6. Click OK.

7. Click Create New.

A dialog appears.

8. Configure these settings:

Setting name	Description
Auth Type	Select which type of HTTP authentication to use: Basic — Clear text, Base64-encoded user name and password. Supports all user queries except NTLM. NTLM users will be ignored if included in the user group. Digest — Hashed user name, realm, and password. Only local users are supported. Other types are ignored if included in the user group. NTLM — Encrypted user name and password. Only NTLM queries are supported. Other types are ignored if included in the user group. For more information on available user types, see Grouping users.
User Group	Select the name of an existing end-user group that is authorized to use the URL in Auth Path.
User Realm	Type the realm, such as `Restricted Area`, to which the Auth Path belongs. The realm is often used by browsers: It may appear in the browser’s prompt for the user’s credentials. Especially if a user has multiple logins, and only one login is valid for that specific realm, displaying the realm helps to indicate which user name and password should be supplied. After authenticating once, the browser may cache the authentication credentials for the duration of the browser session. If the user requests another URL from the same realm, the browser often will automatically re-supply the cached user name and password, rather than asking the user to enter them again for each request. The realm may be the same for multiple authentication rules, if all of those URLs permit the same user group to authenticate. For example, the user group `All_Employees` could have access to the Auth Path URLs `/wiki/Main` and `/wiki/ToDo`. These URLs both belong to the realm named `Intranet Wiki`. Because they use the same realm name, users authenticating to reach `/wiki/Main` usually will not have to authenticate again to reach `/wiki/ToDo`, as long as both requests are within the same browser session. This field does not appear if Auth Type is NTLM, which does not support HTTP-style realms.
Auth Path	Type the literal URL, such as `/employees/holidays.html`, that a request must match in order to invoke HTTP authentication.

9. Click OK.

10. Repeat the previous steps for each user that you want to add to the authentication rules.

11. Group the authentication rule in an authentication policy. For details, see Grouping authorization rules.

Grouping authorization rules

Often, you may want to specify multiple authorization realms to apply to a single server policy. Before you can use authorization rules in a protection profile, you must group them together. (These sets are called “authentication policies” in the web UI).

Authentication policies also contain settings such as connection and cache timeouts that FortiWeb applies to all requests authenticated using this authentication policy.

Alternatively or in addition to HTTP authentication, with SSL connections, you can require that clients present a valid personal certificate. For details, see Certificate Verification.

To configure an authentication policy

1. Before you can configure an authentication policy, you must first configure:

end-users (see Configuring local end-user accounts, Configuring LDAP queries, or Configuring NTLM queries)
user groups (see Grouping users)
one or more authorization rules to select the authorization mechanism, select the user group, and the set of URLs that is the authorization realm (see Applying user groups to an authorization realm)

2. Go to Application Delivery > Authentication and select the Authentication Policy tab.

3. Click Create New.

4. Configure these settings:

Setting name	Description
Name	Type a unique name that can be referenced in other parts of the configuration. Do not use spaces or special characters. The maximum length is 63 characters.
Connection Timeout	Type the connection timeout for the query to the FortiWeb’s query to the remote authentication server in milliseconds. The default is 2,000 (2 seconds). If the authentication server does not answer queries quickly enough, to prevent dropped connections, increase this value.
Cache	Enable if you want to cache authentication query results. Tip: This can improve performance, especially if the connection to the remote authentication server is slow or experiences latency.
Alert Type	Select whether to log authentication failures and/or successes: None — Do not generate an alert email and/or log message. Failed Only — Alert email and/or log messages are caused only by HTTP authentication failures. Successful Only — Alert email and/or log messages are caused only by successful HTTP authentication. All — Alert email and/or log messages are caused for all HTTP authentication attempts, regardless of success or failure. Event log messages contain the user name, authentication type, success or failure, and source address (for example, `User jdoe HTTP BASIC login successful from 172.20.120.46`) when an end-user successfully authenticates. A similar message is recorded if the authentication fails (for example, `User hackers HTTP BASIC login failed from 172.20.120.227`).

5. If you enabled Cache, also configure the following:

Setting name	Description
Cache Timeout	Type the number of seconds that authentication query results will be cached. When a record’s timeout is reached, FortiWeb will remove it from the cache. Subsequent requests from the client will cause FortiWeb to query the authentication server again, adding the query results to the cache again. This setting is applicable only if Cache is enabled. The default value is 300.

Setting name

Description

Cache Timeout

Type the number of seconds that authentication query results will be cached.

When a record’s timeout is reached, FortiWeb will remove it from the cache. Subsequent requests from the client will cause FortiWeb to query the authentication server again, adding the query results to the cache again.

This setting is applicable only if Cache is enabled. The default value is 300.

6. Click OK.

7. Click Create New.

A dialog appears.

8. From the Auth Rule drop-down list, select the name of an authentication rule.

9. Click OK.

10. Repeat the previous steps for each individual rule that you want to add to the authentication policy.

11. To apply the authentication policy, select it in an inline protection profile that is included in a policy (see Configuring a protection profile for inline topologies).

If you have enabled logging, you can also make reports such as “Top Failed Authentication Events By Day” and “Top Authentication Events By User” to identify hijacked accounts or slow brute force attacks. See Reports.