Offloaded authentication and optional SSO configuration

To configure offloaded authentication with optional SSO

1. Before you configure SSO, create one or more of the following authentication server configurations:
   • LDAP (see Configuring an LDAP server)
   • RADIUS (see Configuring a RADIUS server)
2. Add one or more server configurations to an authentication server pool. For details, see Adding servers to an authentication server pool.
3. To use Kerberos authentication delegation, do the following:
   1. Create a Kerberos Key Distribution Center configuration. For details, see Configuring a Kerberos Key Distribution Center (KDC) server.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.
   2. If your client authentication method is Client Certificate Authentication, create the AD user account that FortiWeb uses to authenticate itself on behalf of clients and the corresponding keytab file configuration. For details, see Creating an Active Directory (AD) user for FortiWeb - Keytab File.
4. If you plan to use HTML form authentication, you can customize the HTML pages that FortiWeb presents to clients during the authentication process. For details, see Customizing error and authentication pages (replacement messages).
5. Go to Application Delivery > Site Publish > Site Publish and select the Site Publish 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 Server Policy Configuration category. For details, see Permissions.
6. Click Create New and configure the settings. The settings you select determine which additional settings are displayed:

Name	Enter a unique name that can be referenced in other parts of the configuration, such as cms-publisher1. The maximum length is 63 characters.
Published Site Type	Select one of the following options: Simple String—Published Site contains a literal FQDN (fully qualified domain name). Regular Expression—Published Site contains a regular expression designed to match multiple host names or FQDNs.
Published Site	Enter one of the following: The literal Host: name, such as sharepoint.example.com, that the HTTP requests that match the rule contain (if Published Site Type is Simple String) A regular expression, such as ^*\.example\.edu, that matches all and only the host names that the rule should match (if Published Site Type is Regular Expression). The maximum length is 256 characters. Note: Regular expressions beginning with an exclamation point ( ! ) are not supported. For details about language and regular expression matching, see Regular expression syntax.
Path	Enter the URL of the request for the web application, such as /owa. It must begin with a forward slash ( / ).
Cookieless	Enable to allow cookieless clients to access to Microsoft Exchange servers through Exchange ActiveSync. Note: If Cookieless is enabled, single sign-on (see SSO Support) and authentication cookie (see Authentication Cookie Timeout) will be not available, and HTTP Basic Authentication (see Client Authentication Method) will be the only method to authenticate the clients.
Client Authentication Method	Select one of the following options: HTML Form Authentication—FortiWeb authenticates clients by presenting an HTML web page with an authentication form. When the authentication cookie expires, FortiWeb replies to the first request without a valid authentication cookie with a 200 (OK) status code and injects HTML into the response, showing the user the login page. HTML Basic Authentication—FortiWeb authenticates clients by replying to the request with a 401 (Unauthorized) status code, and the browser displays a traditional, browser-specific authentication prompt. Client Certificate Authentication—FortiWeb validates the HTTP client’s personal certificate using the certificate verifier specified in the associated server policy or server pool configuration. SAML Authentication—FortiWeb uses a SAML server to pass identity information to a service provider via a signed XML document for client authentication. When the authentication cookie expires, FortiWeb replies to the first request without a valid authentication cookie with a 301 (Moved Temporarily) status code, forcing the browser to direct to the authentication page. NTLM Authentication—FortiWeb uses a NTLM server for client authentication. FortiWeb replies to the first request from the client with a 401 (Unauthorized) status code, and the browser displays a traditional, browser-specific authentication prompt. OAuth Authentication—FortiWeb uses an OAuth2.0 server for client authentication. See OAuth Authorization. If Cookieless is enabled (see Cookieless), only HTML Basic Authentication will be available.
Log Off Path Type	Select one of the following options: Simple String—The optional Published Server Log Off Path setting is a literal URL. Regular Expression—The optional Published Server Log Off Path setting is a regular expression designed to match multiple URLs.
Published Server Log Off Path	Optionally, enter one of the following values: If Log Off Path Type is Simple String, enter the URL of the request that a client sends to log out of the application. If Log Off Path Type is Regular Expression, enter a regular expression that matches the logoff URL. Ensure that the value is a sub-path of the Path value. For example, if Path is /owa , the following values are valid: /owa/auth/logoff.aspx /owa/logoff.owa When clients log out of the web application, FortiWeb redirects them to its authentication dialog. Available only when Client Authentication Method is HTML Form Authentication.
Redirect URL After Authentication (Optional)	Specify a URL to redirect users to it after they are successfully authenticated.
Authentication Cookie Timeout	Specify the length of time (in minutes) that passes before the cookie that the site publish rule adds expires and the client must re-authenticate. Valid values are from 0 to 216000 minutes. To configure the cookie with no expiration, specify 0 (the default). The browser only deletes the cookie when the user closes all browser windows. Note: This will be not available if Cookieless is enabled.
Authentication Server Pool	Select the pool of servers that FortiWeb uses to authenticate clients. For details, see Adding servers to an authentication server pool. FortiWeb attempts to authenticate the user using each server in the pool, starting with the top-most item in the list and moving downward. Available only when Client Authentication Method is HTML Form Authentication or HTML Basic Authentication.
SAML Server	Select the SAML server that FortiWeb uses to authenticate clients. For details, see Configuring a Security Assertion Markup Language (SAML) server. Available only when the Client Authentication Method is SAML Authentication.
NTLM Server	Select the NTLM server that FortiWeb uses to authenticate clients. For details, see Configuring an NTLM server. Available only when the Client Authentication Method is NTLM Authentication.
OAuth Server Pool	Select the OAuth server pool that FortiWeb uses to authenticate clients. For details, see OAuth Authorization. Available only when the Client Authentication Method is OAuth Authentication.
Authentication Delegation	Select one of the following options: HTTP Basic—FortiWeb uses HTTP Authorization: headers with Base64 encoding to forward the client’s credentials to the web application. Typically, you select this option when the web application supports HTTP protocol-based authentication. Available only when Client Authentication Method is HTML Form Authentication or HTML Basic Authentication Kerberos—After it authenticates the client via the HTTP form or HTTP basic method, FortiWeb obtains a Kerberos service ticket for the specified web application on behalf of the client. It adds the ticket to the HTTP Authorization: header of the client request with Base64 encoding. Available only when Client Authentication Method is HTML Form Authentication or HTML Basic Authentication Kerberos Constrained Authentication—After it authenticates the client’s certificate, FortiWeb obtains a Kerberos service ticket for the specified web application on behalf of the client. It adds the ticket to the HTTP Authorization: header of the client request with Base64 encoding. Available only when Client Authentication Method is Client Certificate Authentication. Radius Constrained Authentication—After it authenticates the client’s certificate, FortiWeb sends a RADIUS access-request to the RADIUS server, using the RFC822 name (email address) of the certificate’s Subject Alternative Name. For some applications a prefix should be added to the mail address sent to the RADIUS server (example: “app1/forename.surname@org.com”). Use RADIUS Username Format to define the format of the extracted user name. Available only when Client Authentication Method is Client Certificate Authentication. Form Based Delegation— FortiWeb uses Form Based Delegation to forward the client’s credentials to the server. Available only when Client Authentication Method is HTML Form Authentication. No Delegation—FortiWeb does not send the client’s credentials to the web application. Select this option when the web application has no authentication of its own or uses HTML form-based authentication. Note: If the web application uses HTML form-based authentication, the client is required to authenticate twice: once with FortiWeb and once with the web application’s form. NTLM—FortiWeb uses NT LAN Manager (NTLM) for authentication delegation. This is a challenge/response authentication protocol that FortiWeb uses to verify the identify of clients attempting to connect to the server(s). Note: If the POST method request triggers NTLM authentication, the request body cannot exceed 100M. To work with the Kerberos options, web applications require a specific Windows authentication configuration. For details, see Configuring Windows Authentication for Kerberos authentication delegation. If FortiWeb uses a RADIUS server configuration in the authorization server pool to autheticate the client and RSA SecurID is selected for that server configuration, any authentication delegation settings in this rule are ignored.
RADIUS Server	Select the RADIUS server to perform additional authorization.
RADIUS Username Format	Enter the username format that FortiWeb uses to send the user email address to the RADIUS server for authorization. For example, let's say the email address of the user account is example@abc.com. If the format is USERNAME, FortiWeb will send example to RADIUS server. If the format is RAWNAME, FortiWeb will send example@abc.com to RADIUS server. You can add any letter before or/and after USERNAME/RAWNAME. FortiWeb will combine them together and send it to RADIUS server. So, to send app1/example@abc.com, you can enter either app1/USERNAME@abc.com or app1/RAWNAME. Note: USERNAME and RAWNAME should be exactly as is, and in upper case. This option is available only when Authentication Delegation is Radius Constrained Authentication.
Form Based Delegation	Select the Form Based Delegation you have created. See Using Form Based Delegation.
Append Custom Header	Enable this option to forward the username to the back-end server in HTTP header.
Custom Header Name	Enter a name for the HTTP header. The default name is X-FortiWeb-Username. You can change it to any name as you desire, e.g. X-FortiWeb-Uname, useraccount. Special characters are not supported.
Custom Header Value Format	Enter the format for the value, such as aaa-username-bbb, xxx-username, or username. Special characters are not supported. It must contain "username" in the value format. FortiWeb replaces the "username" with the actual username when forwarding the HTTP header to the back-end server. For example, if you set the HTTP header name as "useraccount", the value format as "xxx-username", and the traffic is from a user whose username is David, FortiWeb forwards the HTTP header "useraccount:xxx-David" to the back-end server. Please note that if you include more than one "username" in the value format, e.g. xxx-username-username, only the first "username" will be replaced with the actual username, such as, xxx-david-username.
Kerberos Type	Two kinds of authorization mechanisms are available, which are used by web servers to retrieve the Kerberos tickets: KRB5 SPNEGO Available only when Authentication Delegation is Kerberos.
Username Location in Certificate	Use one of the following options to specify how FortiWeb determines the client username: SAN - UPN—Using the certificate’s subjectAltName (Subject Alternative Name or SAN) and User Principal Name (UPN) values. These values that contain the username in certificates issued in a Windows environment. For example: username@domain SAN - Email—Using the certificate’s subjectAltName (Subject Alternative Name or SAN) and the email address value in the certificate’s Subject information. Subject - Email—Using the email address value in the certificate’s Subject information. Note: Because the email value can be an alias rather than the real DC (domain controller) domain, the most reliable method for determining the username is SAN - UPN. Available only when the Client Authentication Method is Client Certificate Authentication and the Authentication Delegation is Kerberos Constrained Delegation.
Delegation Mode	Select one of the following: Single Server—Allows you to specify a Delegated HTTP Service Principal Name for the site publish rule. Server Pool—Allows you to specify a Service Principal Name Pool for the site publish rule. This option is available only when the Authentication Delegation is Kerberos or Kerberos Constrained Delegation.
Delegated HTTP Service Principal Name	Specify the Service Principal Name (SPN) for the web application that clients access using this site publish rule. For details, see Configuring Service Principal Names for Kerberos authentication. Available only when Authentication Delegation is Kerberos or Kerberos Constrained Delegation.
Service Principal Name Pool	Select the SPN pool for the application that clients access using this site publish rule. For details, see Configuring Service Principal Names for Kerberos authentication. Available only when Authentication Delegation is Kerberos or Kerberos Constrained Delegation.
Keytab File	Select the keytab file configuration for the AD user that FortiWeb uses to obtain Kerberos service tickets for clients. To add a keytab configuration, go to Application Delivery > Site Publish > Keytab File. For instructions on how to generate the keytab file, see Creating an Active Directory (AD) user for FortiWeb - Keytab File. Available only when Authentication Delegation is Kerberos Constrained Delegation.
Service Principal Name for Keytab File	Specify the Service Principal Name (SPN) of the AD user that is a delegator. It is the SPN that you used to generate the keytab specified by Keytab File. For details, see Creating an Active Directory (AD) user for FortiWeb - Keytab File. For example, host/forti-delegator.dc1.com@DC1.COM. For a Fortiwebsite publishing configuration, a valid SPN requires the suffix @<domain> (for example, @DC1.COM). Available only when Authentication Delegation is Kerberos Constrained Delegation.
Default Domain Prefix Support	Select to allow users in environments that require users to log in using both a domain and username to log in with just a username. Also specify Default Domain Prefix. In some environments, the domain controller requires users to log in with the username format domain\username. For example, if the domain is example.com and the username is user1, the user enters EXAMPLE\user1. Alternatively, enable this option and enter EXAMPLE for Default Domain Prefix. The user enters user1 for the username value and FortiWeb automatically adds EXAMPLE\ to the HTTP Authorization: header before it forwards it to the web application. Available only when Authentication Delegation is HTTP Basic, Kerberos, or the Client Authentication Method is NTLM Authentication.
Default Domain Prefix	Enter a domain name that FortiWeb adds to the HTTP Authorization: header before it forwards it to the web application. Available only when Default Domain Prefix Support is enabled. When Authentication Delegation is Kerberos, ensure that the prefix you enter is the full domain name (for example, example.com).
SSO Support	Enable for single sign-on support. For example, the website for this rule is www1.example.com and SSO Domain is .example.com. After FortiWeb authenticates the client for www1.example.com, the client can access www2.example.com without authenticating a second time. Site publishing SSO sessions exist on FortiWeb only; they are not synchronized to the authentication or accounting server. Therefore, SSO is not shared with non-web applications. For SSO with other protocols, see the documentation for your FortiGate or other firewall. Note: This will be not available if Cookieless is enabled.
SSO Domain	Type the domain suffix of Host: names that can share this rule’s authentication sessions, such as .example.com. Include the period ( . ) that precedes the host’s name.
Alert Type	Select whether to log authentication failures, successes, or both: None—Do not generate an alert email or log message. Failed Only—Only authentication failures generate alert email and log messages. Successful Only—Only successful authentication generates alert email or log messages. All—All HTTP authentication attempts, regardless of success or failure, generate alert email, log messages, or both. Event log messages contain the user name, authentication type, success or failure, and source address (for example, User jdoe [Site Publish] login successful from 172.0.2.5) when an end-user successfully authenticates. A similar message is recorded if the authentication fails (for example, User hackers [Site Publish] login failed from 172.0.2.5).

7. Click OK.
8. Go to Application Delivery > Site Publish > Site Publish and select the Site Publish Policy tab.
9. Click Create New.
10. In Name, type a unique name that can be referenced in other parts of the configuration. The maximum length is 63 characters.
11. If you want to prevent users from making further attempts to log in after a specified number of failed login attempts, enable Account Lockout and complete the following settings:

Max Login Failures	Enter the number of times that a user can attempt to log in before FortiWeb prevents the user from attempting to log in again. FortiWeb determines whether the user exceeded this threshold based on the number of login attempts that happen within the time period specified by Within. If the user exceeds the threshold and attempts to log in again during the time period configured by Account Block Period, FortiWeb returns an "Account blocked!" message to the user. You can customize the web page that FortiWeb returns to the blocked user. For details, see Customizing error and authentication pages (replacement messages).
Within	Enter the length of time, in minutes, which FortiWeb uses to determine if the user has exceeded the maximum number of login attempts specified by Max Login Failures. Take the configuration that maximum of 3 attempts within 5 minutes is allowed for a example, if a user fails the login for 3 times within the 5 minutes, FortiWeb will lock the user out for a specified period (Account Block Period). However, if the user fails login for 2 times within the 5 minutes, FortiWeb will not lock out the user for the third failure happens within next 5 minutes.
Account Block Period	Enter the length of time FortiWeb prevents a user from attempting to log in again after the user has exceeded the number of login attempts specified by Max Login Failures.

12. If you want to limit the number of concurrent logins per account, enable Limit Concurrent Users Per Account complete the following settings:
    

Limit Concurrent Users Per Account	Enable to limit the number of concurrent logins per account. The active accounts are shown in Active Users page. To view it, click the Add Monitor icon in the navigation bar, then click the Add icon before Active Users.
Maximum Concurrent Users	Specify the maximum number of concurrent logins using the same account.
Session Idle Timeout	When a session is idled for the specified period of time, the Concurrent Users count will be renewed. The user who is timed-out needs to re-log in.

13. If you want to prevent users from credential stuffing attacks, enable Credential Stuffing Defense and complete the following settings:

Credential Stuffing Defense	Enable to use FortiGuard's Credential Stuffing Defense database to prevent against Credential Stuffing attacks. When this setting is enabled, FortiWebwill evaluate the username (Username Field) and password (Password Field) of the matched login requests against the Credential Stuffing Defense database to identify whether the paired username/password has been spilled. If it has, the specified Action triggers and Trigger Policy is applied. Caution: FortiWeb has no built-in Credential Stuffing Defense database. At least one FortiGuard update is required to install the database, otherwise this feature is ineffective. For details, see Connecting to FortiGuard services.
Credential Stuffing Online Check	Enable to execute Credential Stuffing Defense using an online query in addition to the local DB query. The online database is larger and covers additional leaked credentials from data breaches.
Test	To verify whether the local or online Credential Stuffing database works properly, you can click the Test button and enter a user name and password which you believe is a malicious user, then check the scan result returned by the system.
Action	Select the action that FortiWeb will take against a request when a paired username/password is found in Credential Stuffing Defense database: Alert—Accept the request and generate an alert email and/or log message. Alert & Deny—Block the request (or reset the connection) and generate an alert email and/or log message. You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages). Note: Because the deny action is not supported in Offline Protection mode, this option has the same effect as Alert. Deny (no log)—Block the request (or reset the connection). Period Block—Block subsequent requests from the client for a specified number of seconds. You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages). Caution: This option is not supported in Offline Protection mode.
Block Period	Type the number of seconds that you want to block a request when a paired username/password is found in Credential Stuffing Defense database. This setting is available only if Action is set to Period Block. The valid range is from 1 to 3,600 seconds (1 hour). See also Blocked IPs.
Severity	When the credential stuffing defense generates an attack log, each log message contains a Severity Level (severity_level) field. Select which severity level FortiWeb uses when it takes the specified action: Informative Low Medium High The default value is Medium.
Trigger Policy	Select which trigger, if any, that FortiWeb will use when it logs or sends an alert email about the credential stuffing hit. For details, see Configuring triggers.

14. Click Create New and in Rule, select the name of a site publishing rule.
15. Repeat the previous step for each web application that is part of the SSO domain.
16. Click OK.
17. Select the site publishing policy in an inline web protection profile. The profile must be used in the policy applying your domain’s virtual servers. For details, see Configuring a protection profile for inline topologies.
18. To verify the configuration, log in to one of the web applications, then log in to another web application in the same domain that should be part of the SSO domain.

See also

• Offloading HTTP authentication & authorization
• Two-factor authentication
• RSA SecurID authentication
• Using Kerberos authentication delegation