Fortinet Document Library

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:


Table of Contents

Administration Guide

Site Publishing (Single sign-on)

You can configure single sign-on (SSO) and combination access control and authentication (called “site publishing” in the web UI) instead of configuring simple HTTP authentication rules if:

  • Your users will be accessing multiple web applications on your domain.
  • You have defined accounts centrally on an LDAP server (such as Microsoft Active Directory) or a RADIUS server.

Unlike HTTP authentication rules, SSO does not require your users to authenticate each time they access separate web applications in your domain.

For example, if you configure HTML form authentication, when FortiWeb receives the first request, it returns an HTML authentication form.

FortiWeb’s HTTP authentication form

FortiWeb forwards the client’s credentials in a query to the authentication server. Once the client is successfully authenticated, if you have configured FortiWeb to delegate, FortiWeb forwards the credentials to the web application. The server’s response is returned to the client. Until the session expires, subsequent requests from the client to the same or other web applications in the same domain do not require the client to authenticate again.

You can use the SSO feature to replace your discontinued Microsoft Threat Management Gateway. With SSO enabled, you can use FortiWeb as a portal for multiple applications such as SharePoint, Outlook Web Application, Lync, and/or IIS. Users log in once to use any or all of those resources.

When you configure SSO, FortiWeb uses the authentication method for the first site publish rule that matches. Therefore, you cannot specify different authentication methods for individual web applications in the same SSO domain.

For example, you can create a site publish rule that allows users to access Outlook Web App (OWA) via HTML Form Authentication and a rule that allows them to access Exchange via HTTP Basic Authentication. However, to ensure FortiWeb controls access to each application with the correct authentication method, do not enable SSO for the rules.

If you do not want to apply SSO, but still want to publish multiple sites through the same server policy, apply the same steps, except do not enable SSO.
See also

Two-factor authentication

By default, FortiWeb supports RADIUS authentication that requires users to provide a secondary password, PIN, or token code in addition to a username and password (two-factor authentication).

When the RADIUS server does not require two-factor authentication, form-based authentication via a RADIUS query is complete after the user enters a valid username and password.

If the RADIUS server requires two-factor authentication, after users enter a valid username and password, RADIUS returns an Access-Challenge response. FortiWeb displays a second authentication form that allows users to enter a token code (e.g., an RSA SecurID token code).

Authentication form for two-factor authentication

Alternatively, FortiWeb allows users to authenticate without using the second form by entering both their password and token code in the password field of the initial form. The RADIUS server extracts the token code automatically. The combined entry uses the following format:

<password><token_code>

For example, if the password is fortinet and the code is 123456, the user enters fortinet123456 in the Password field.

Note: When users enter the password and token code together, any delegation configuration in the site publish rule does not work. Delegation requires a password, and the AD server cannot obtain the password from the combined value.

See also

RSA SecurID authentication

FortiWeb’s default two-factor authentication feature supports RADIUS authentication using RSA SecurID. For details, see Two-factor authentication.

Alternatively, you can enable the RSA SecurID option in the site publish rule, which allows users to authenticate using their username and RSA SecurID token code. Instead of the regular authentication form, FortiWeb displays a form that captures these two values only. For details, see Adding servers to an authentication server pool.

RSA SecurID authentication without a password

When you enable RSA SecurID, the authentication delegation options in the site publish rule are not available. These options depend on a password, which FortiWeb’s RSA SecurID form does not capture.

See also

Changing user passwords at login

By default, FortiWeb’s HTTP authentication form provides users with the option to change their password after a successful login. When it is enabled, FortiWeb displays a password change form after the user authenticates successfully.

This feature requires the following configuration:

  • The authentication server is Microsoft Active Directory (AD) and provides LDAP over SSL (LDAPS) service.
  • In the LDAP query configuration, Bind Type is Regular. You do not need to enable Secure Connection to support the password change at login feature. For details, see Configuring an LDAP server.
  • For the site publish rule configuration, Authentication Validation Method is LDAP. For details, see Offloaded authentication and optional SSO configuration.

Site Publishing (Single sign-on)

You can configure single sign-on (SSO) and combination access control and authentication (called “site publishing” in the web UI) instead of configuring simple HTTP authentication rules if:

  • Your users will be accessing multiple web applications on your domain.
  • You have defined accounts centrally on an LDAP server (such as Microsoft Active Directory) or a RADIUS server.

Unlike HTTP authentication rules, SSO does not require your users to authenticate each time they access separate web applications in your domain.

For example, if you configure HTML form authentication, when FortiWeb receives the first request, it returns an HTML authentication form.

FortiWeb’s HTTP authentication form

FortiWeb forwards the client’s credentials in a query to the authentication server. Once the client is successfully authenticated, if you have configured FortiWeb to delegate, FortiWeb forwards the credentials to the web application. The server’s response is returned to the client. Until the session expires, subsequent requests from the client to the same or other web applications in the same domain do not require the client to authenticate again.

You can use the SSO feature to replace your discontinued Microsoft Threat Management Gateway. With SSO enabled, you can use FortiWeb as a portal for multiple applications such as SharePoint, Outlook Web Application, Lync, and/or IIS. Users log in once to use any or all of those resources.

When you configure SSO, FortiWeb uses the authentication method for the first site publish rule that matches. Therefore, you cannot specify different authentication methods for individual web applications in the same SSO domain.

For example, you can create a site publish rule that allows users to access Outlook Web App (OWA) via HTML Form Authentication and a rule that allows them to access Exchange via HTTP Basic Authentication. However, to ensure FortiWeb controls access to each application with the correct authentication method, do not enable SSO for the rules.

If you do not want to apply SSO, but still want to publish multiple sites through the same server policy, apply the same steps, except do not enable SSO.
See also

Two-factor authentication

By default, FortiWeb supports RADIUS authentication that requires users to provide a secondary password, PIN, or token code in addition to a username and password (two-factor authentication).

When the RADIUS server does not require two-factor authentication, form-based authentication via a RADIUS query is complete after the user enters a valid username and password.

If the RADIUS server requires two-factor authentication, after users enter a valid username and password, RADIUS returns an Access-Challenge response. FortiWeb displays a second authentication form that allows users to enter a token code (e.g., an RSA SecurID token code).

Authentication form for two-factor authentication

Alternatively, FortiWeb allows users to authenticate without using the second form by entering both their password and token code in the password field of the initial form. The RADIUS server extracts the token code automatically. The combined entry uses the following format:

<password><token_code>

For example, if the password is fortinet and the code is 123456, the user enters fortinet123456 in the Password field.

Note: When users enter the password and token code together, any delegation configuration in the site publish rule does not work. Delegation requires a password, and the AD server cannot obtain the password from the combined value.

See also

RSA SecurID authentication

FortiWeb’s default two-factor authentication feature supports RADIUS authentication using RSA SecurID. For details, see Two-factor authentication.

Alternatively, you can enable the RSA SecurID option in the site publish rule, which allows users to authenticate using their username and RSA SecurID token code. Instead of the regular authentication form, FortiWeb displays a form that captures these two values only. For details, see Adding servers to an authentication server pool.

RSA SecurID authentication without a password

When you enable RSA SecurID, the authentication delegation options in the site publish rule are not available. These options depend on a password, which FortiWeb’s RSA SecurID form does not capture.

See also

Changing user passwords at login

By default, FortiWeb’s HTTP authentication form provides users with the option to change their password after a successful login. When it is enabled, FortiWeb displays a password change form after the user authenticates successfully.

This feature requires the following configuration:

  • The authentication server is Microsoft Active Directory (AD) and provides LDAP over SSL (LDAPS) service.
  • In the LDAP query configuration, Bind Type is Regular. You do not need to enable Secure Connection to support the password change at login feature. For details, see Configuring an LDAP server.
  • For the site publish rule configuration, Authentication Validation Method is LDAP. For details, see Offloaded authentication and optional SSO configuration.