Offloading HTTP authentication & authorization

If a website does not support RFC 2617 (http://tools.ietf.org/html/rfc2617) 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. For details, see Supported features in each operation mode.

Authentication can use either locally-defined accounts or remotely-defined accounts whose credentials are confirmed with the authentication following authentication servers:

LDAP queries
RADIUS queries
NTLM queries
KDC queries
SAML queries
TACACS+ queries

based upon the end-user’s confirmed identity or URL he or she 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 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

You can also require the end-user to present a personal certificate in order to securely authenticate. For details, see How to apply PKI client authentication (personal certificates).

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. For details, 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. For details, see Configuring an LDAP server, Configuring a Terminal Access Controller Access Control System (TACACS)+ server, or Configuring an NTLM server.

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

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

Group authorization rules into an authorization policy. See Grouping authorization rules.

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

Select the inline protection profile in a server policy. See Configuring an HTTP server policy.

When you have configured HTTP authentication

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

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.

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

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.

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. For details 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

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.
Click Create New.
Configure these settings:

Name

Enter 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

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

The maximum length is 63 characters.

Password

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

Click OK.
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 an LDAP server

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:

https://docs.fortinet.com/document/fortiweb/

For end-user queries, configure Connection Timeout instead.

To configure an LDAP server

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.
Click Create New.
A dialog appears.
Configure these settings:

Name	Enter a unique name that can be referenced in other parts of the configuration. The maximum length is 63 characters.
Server IP/Domain Name	Enter 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	Enter 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	Enter 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 256 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	Enter 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	Enter 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 256 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 Typeis Regular and Group Authentication is enabled.
Group DN	Enter 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 256 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.

Click OK.
If you enabled Secure Connection, upload the certificate of the CA that signed the directory server’s certificate. For details, see Uploading trusted CA certificates.
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.
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. For details, 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 details, 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. For details, see Adding servers to an authentication server pool.

Example for a configuration for AD

The following sample values are part of an LDAP 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 a RADIUS server

FortiWeb can use RADIUS queries to authenticate and authorize end-users’ HTTP requests. For details, see Offloading HTTP authentication & authorization. FortiWeb can also use RADIUS 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 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:

https://docs.fortinet.com/document/fortiweb/

For end-user queries, configure Connection Timeout instead.

To configure a RADIUS server

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.
Click Create New.
A dialog appears.
Configure these settings:

Name	Enter a unique name that can be referenced in other parts of the configuration. The maximum length is 63 characters.
Server IP	Enter the IP address of the primary RADIUS server.
Server Port	Enter the port number where the RADIUS server listens. The default port number is 1812.
Server Secret	Enter 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	Enter the IP address of the secondary RADIUS server, if applicable.
Secondary Server Port	Enter the port number where the RADIUS server listens. The default port number is 1812.
Secondary Server Secret	Enter 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	Enter the NAS IP address and Called Station ID (for more information about RADIUS Attribute 31, see RFC 2548 (http://www.ietf.org/rfc/rfc2548.txt) 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.

Click OK.
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.
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. For details, see Grouping remote authentication queries and certificates for administrators.

For access profiles, FortiWeb appliances support RFC 2548 (http://www.ietf.org/rfc/rfc2548.txt) Microsoft Vendor-specific RADIUS Attributes. If you do not want to use them, you can configure them locally instead. For details, 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.

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. For details, see Adding servers to an authentication server pool.

Configuring an NTLM server

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 details, see Applying user groups to an authorization realm.

To configure an NTLM server

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.
Click Create New.
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. The maximum length is 63 characters.
For Server IP, type the IP address of the NTLM server to query.
For Port, type the TCP port number where the NTLM server listens for queries.
Click OK.
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 a Kerberos Key Distribution Center (KDC) server

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 details, see Using Kerberos authentication delegation and Offloaded authentication and optional SSO configuration.

To configure a KDC server

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 Writepermission to items in the Auth Users category. For details, see Permissions.

Click Create New and complete the following settings:

Name	Enter a name that can be referenced by other parts of the configuration. The maximum length is 63 characters.
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.

Click OK.
Click Create New to add multiple servers for the realm.
Configure these settings:

Server IPv4/IPv6

Enter the IP address of the KDC.

In most cases, the KDC is located on the same server as the DC.

Server Port

Enter the port the KDC uses to listen for requests.
Click OK.

Configuring a Security Assertion Markup Language (SAML) server

You can use a SAML server in a site publish rule to handle client authentication for web browser single sign-on (SSO).

SAML is an open standard for exchanging authentication and authorization data between parties, and is often used for exchanging such data between an identity provider and a service provider.

To configure a SAML server

Go to User > Remote Server and select the SAML 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.
Click Create New and complete the following settings:

Name	Enter a name that can be referenced by other parts of the configuration. The maximum length is 63 characters.
Entity ID	Enter the URL for the SAML server. The communications protocol must be HTTPS.
Service Path	Enter a path for the SAML server at the URL you specified in Entity ID.
Assertion Consumer Service
Binding Type	Select the binding that the server will use to transport the SAML authentication request to the IDP.
Path	Enter a partial URL that the IDP will use to confirm with the service provider that a user has been authenticated.
Single Logout Service
Binding Type	Select the binding that the server will use when the service provider initiates a single logout request: `POST`—SAML protocol messages are transported via the user's browser in an XHTML document using base64-encoding. `REDIRECT`—SAML protocol messages will be carried in the URL of an HTTP `GET` request. Because the length of URLs is limited, this option is best for shorter messages.
Path	Enter a partial URL that the IDP will use to confirm with the service provider that a user has been logged out.
Identity Provider Metadata
Metadata	Click Choose File to upload an IDP (Identity Provider) metadata file for the SAML server. If the file is valid, the Entity ID below will populate. The metadata file is provided by the Identity Provider such as AD FS, TestShib and OneLogin. It defines the EntityID, Endpoints (Single Sign On Service Endpoint, Single Logout Service Endpoint), etc. FortiWeb parses the information in the metadata file and redirects the user's authentication request to the identity provider accordingly. After the user's identity is authenticated, the identity provider responds to FortiWeb with a SAML authentication assertion. Note: When you configure SAML Single Sign-on with the Identify Provider, make sure the user information (UPN or Email) is mapped to EPPN (urn:oid:1.3.6.1.4.1.5923.1.1.1.6), because FortiWeb uses the value of the EPPN attribute to identify users uniquely. The following is an example of the OneLogin SAML Test Connector configurations:
Entity ID	The Entity ID will populate if the IDP metadata file for the SAML server that you uploaded in Metadata is valid.

Click OK.

Configuring a Terminal Access Controller Access Control System (TACACS)+ server

TACACS+ authentication is now supported for FortiWeb admin users. FortiWeb can also use TACACS+ queries to authenticate administrators’ access to the web UI or CLI. For details, see Grouping remote authentication queries and certificates for administrators.

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

When authenticating administrators, and your TACACS+ 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:

https://docs.fortinet.com/document/fortiweb/

To configure a TACACS+ server

Go to User > Remote Server and select the TACACS+ 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.
Click Create New.
A dialog appears.
Configure these settings:

Name	Enter a unique name that can be referenced in other parts of the configuration. The maximum length is 63 characters.
Server IP/Name	Enter the IP address or domain name of the TACACS+ server.
Server Secret	Enter the TACACS+ server secret key for the TACACS+ server.
Authentication Type	Select Auto to automatically assign an authentication type or select Specify to specify a type.
Type	Select one authentication type of the TACACS+ server. MSCHAP: this type only includes a START message and a REPLY message. The START message must include the username and data information, of which the username is stored in the user field, while the data in the data field; the data information must include session_id, MS-challenge, and MS-authentication. CHAP: this type only includes a START message and a REPLY message. The START message must include the username and data information, of which the username is stored in the user field, while the data in the data field; the data information must include session_id, challenge, and authentication. PAP: this type only includes a START message and a REPLY message. The START message must include the username and password information, of which the username is stored in the user field, while the password in the data field; no encryption is required for the message. ASCII: this type includes the START message, REPLY message, and CONTINUE message; both the START message and the CONTINUE message can carry the username information. Available only if Specify in Authentication Type is selected.

Click OK.
Return to User > Remote Server, select the TACACS+ Server tab, double-click the row of the query, then click the Test TACACS+ button to verify that FortiWeb can connect to the server, and that the query is correctly configured.
To allow administrator accounts to access the FortiWeb web UI, select the query in a remote authentication query group. For details, see Grouping remote authentication queries and certificates for administrators.

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. For details, see Configuring an LDAP server and Configuring a RADIUS server).

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

Go to Application Delivery > Site Publish > Authentication Server Pool.
Click Create New, enter a name for the pool, and then click OK.
Click Create New and complete the following settings:

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 details, 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 details, see Two-factor authentication.

Click OK.
Add any other additional servers you want in the pool.
To use the pool, select it when you configure a site publish rule. For details, see Offloaded authentication and optional SSO configuration

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

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 these sections:

Configuring local end-user accounts
Configuring an LDAP server
Configuring a RADIUS server
Configuring an NTLM server
Configuring a Terminal Access Controller Access Control System (TACACS)+ server
Configuring a Security Assertion Markup Language (SAML) server

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.

Go to User > User Group > User Group.

Click Create New.

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.

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.

Click OK.

Click Create New.

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.

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.

Click OK.

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

Select the user group in an authorization rule. For details, 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 Site Publishing (Single sign-on).

To configure an authentication rule

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.
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.
Click Create New.
In Name, type a name that can be referenced by other parts of the configuration. The maximum length is 63 characters.
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.

Click OK.

Click Create New.

Configure these settings:

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 details about 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.

Click OK.

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

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 Configuring an HTTP server policy.

To configure an authentication policy

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

End-users (see Configuring local end-user accounts, Configuring an LDAP server, or Configuring an NTLM server)
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)

Go to Application Delivery > Authentication and select the Authentication Policy 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.

Click Create New.

Configure these settings:

Name	Type a unique name that can be referenced in other parts of the configuration. 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`).

If you enabled Cache, also configure the following:

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.

Click OK.

Click Create New.

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

Click OK.

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

To apply the authentication policy, select it in an inline protection profile that is included in a policy. For details, 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. For details, see Reports.