Centralized user authentication with authentication servers

A university hosts multiple web applications for its community, including:

• Student Portal (https://students.uex.edu) – For students to access grades, schedules, and course materials.

• Faculty Portal (https://faculty.uex.edu) – For faculty members to upload grades, manage courses, and communicate with students.

Challenges:

• Password complexity, expiration, and reuse policies vary across applications, leading to weak security practices.

• Inconsistent role definitions might grant users inappropriate access to sensitive resources.

• Users must log in separately for each application, resulting in a poor user experience.

The university wants to:

• Deploy an on-premise authentication server to solve this problems,

• Use their Web Application Firewall (WAF) (e.g., FortiWeb) to seamlessly integrate with the authentication server to protect their applications and facilitate secure access.

Solutions by FortiWeb

FortiWeb can act as an authentication proxy connecting to authentication servers to handle authentication requests on behalf of the back-end application servers.

Key functions offered by FortiWeb when working as an authentication proxy

• Authentication Handling:

  • When a user attempts to access a protected application, the request first reaches FortiWeb instead of the back-end server.

  • If authentication is required, FortiWeb prompts the user to provide credentials (e.g., username and password) and forwards them to the configured authentication servers for validation.

• User Attribute Forwarding (with LDAP):

  • When integrated with an LDAP server, FortiWeb can retrieve user attributes (e.g., roles, email, department) during authentication and forward them to the back-end servers via HTTP headers.

  • This enables the application server to personalize content or enforce role-based access control (RBAC).

• Single Sign-On (SSO):

  • FortiWeb supports SSO when integrated with authentication servers, allowing users to log in once and access multiple applications seamlessly without re-entering credentials.

• Multi-Factor Authentication (MFA) (with RADIUS):

  • When integrated with a RADIUS server, FortiWeb can enforce MFA by requiring users to provide an additional form of verification (e.g., one-time passwords) after entering their primary credentials.

Benefits of Using FortiWeb as an Authentication Proxy

• Offloads Authentication Tasks: Reduces the burden on back-end servers by centralizing authentication processes at the FortiWeb layer.

• Enhanced Security: Inspects all traffic for threats before granting access, ensuring only legitimate users reach protected resources.

• Streamlined User Experience: Simplifies the login process across multiple applications with Single Sign-On (SSO);

• Role-Based Access Control (RBAC) Enabled: Improves application functionality and personalization by forwarding user names or user attributes to the back-end servers.

• Scalable and Flexible: Supports various authentication mechanisms, including LDAP, RADIUS, and NTLM; Integrates easily with existing infrastructure.

• Compliance: Helps meet regulatory requirements by supporting Multi-Factor Authentication (MFA) and centralized logging for audit trails.

Configurations on FortiWeb

• Step 1: Adopting an authentication server

  • Authentication protocols supported by FortiWeb

  • Leverage an LDAP sever for user account management in this scenario

• Step 2: Configure an LDAP server pool

• Step 3: Configure a site publish policy for University Portals

• Step 4: Optional: Configure forwarding of LDAP user attributes

  • Step 4.1: Specify the attributes to be retrieved

  • Step 4.2: Reference the attribute in a site publish rule

  • LDAP attribute retrieval example

Step 1: Adopting an authentication server

Adopting an authentication server that uses a protocol supported by FortiWeb—such as LDAP, RADIUS, or NTLM—allows the university to meet its authentication and access control needs.

Authentication protocols supported by FortiWeb

FortiWeb supports the following authentication protocols and mechanisms when connecting to the authentication server:

• LDAP is a protocol for accessing and managing directory information, such as user accounts and group memberships, in a hierarchical database. Its key features include:

  • Primarily used for directory services (e.g., Active Directory, OpenLDAP).

  • Allows querying and modifying user attributes (e.g., usernames, emails, roles). It plays an important roles in Role Based Access Control (RBAC).

  • Commonly used for authentication and user account management.

  • LDAP relies on credential-based authentication, but credentials are sent in clear text unless encrypted (e.g., using LDAPS), which may raise security concerns if not properly secured.

• RADIUS is a protocol for centralized Authentication, Authorization, and Accounting (AAA) for network access. Its key features include:

  • Support of MFA or token-based authentication.

  • Supports accounting for tracking user activity (e.g., time logged in, bandwidth usage).

  • Often integrated with a back-end directory (e.g., LDAP or Active Directory) for credential storage. While some RADIUS servers allow a local user database for small-scale deployments, this is static and lacks the advanced user management features of LDAP.

• NTLM is a Microsoft proprietary authentication protocol, often used for backward compatibility with legacy systems or as a fallback when Kerberos is unavailable. It is no longer considered a best practice.

Leverage an LDAP sever for user account management in this scenario

Each authentication server has unique strengths and limitations. For the university's scenario which requires both user credential validation and role-based access control (RBAC), an LDAP server is a suitable choice. LDAP supports adding user attributes (e.g., usernames, emails, roles) to user accounts, which can be leveraged to define RBAC rules on the back-end server. These rules ensure users are granted access to resources appropriate for their roles. FortiWeb enhances this setup by forwarding user attributes to the back-end servers, streamlining the implementation of RBAC.

After setting up the LDAP server, refer to step 2 to configure FortiWeb to connect to it for user authentication validation.

Step 2: Configure an LDAP server pool

When merging users from the Student Portal (https://students.uex.edu) and Faculty Portal (https://faculty.uex.edu) into a centralized LDAP system, you can use Organizational Units (OUs) in the LDAP directory to create a hierarchical structure that reflects the organization of your university. Assuming you have the following LDAP directory:

dc=uex,dc=edu

├── ou=People

│ ├── uid=jdoe,ou=Faculty,dc=uex,dc=edu

│ ├── uid=abush,ou=Student,dc=uex,dc=edu

│ ├── uid=asmith,ou=Faculty,dc=uex,dc=edu

├── ou=Groups

├── cn=faculty

│ ├── member: uid=jdoe,ou=Faculty,dc=uex,dc=edu

│ ├── member: uid=asmith,ou=Faculty,dc=uex,dc=edu

├── cn=student

│ ├── member: uid=abush,ou=Student,dc=uex,dc=edu

├── cn=admin

The LDAP server configurations on FortiWeb can be set as follows to perform user authentication and directory queries.

1. Go to User > Remote Server and select the LDAP Server tab.
   
2. Click Create New.
3. Configure these settings:

Name	University Portal LDAP
Server IP/Domain Name	Specify the IP address or domain name of the LDAP server FortiWeb will connect to.
Server Port	Enter the port number on which the LDAP server listens for connections. Default Ports: 389 for non-secure connections or STARTTLS-secured connections. 636 for SSL-secured (LDAPS) connections. Ensure the port matches the encryption setting in Secure Connection.
Common Name Identifier	uid
Distinguished Name	dc=uex,dc=edu FortiWeb will search within the dc=uex,dc=edu directory to locate the uid=jdoe.
Bind Type	Regular Regular Bind in FortiWeb's LDAP configuration works as follows: FortiWeb uses the pre-configured User DN and Password to authenticate itself to the LDAP server. This authentication grants FortiWeb elevated privileges to perform detailed searches within the LDAP directory. The search scope is limited to the hierarchy level of the specified User DN, in this example, dc=uex,dc=edu.
User DN	cn=admin,dc=uex,dc=edu
Password	Enter the password of the Centralized user authentication with authentication servers.
Filter	Optional. Use Filter if you want to narrow down the results based on specified attributes. For example: (&(objectClass=person)(memberOf=cn=faculty,ou=Groups,dc=uex,dc=edu)) This filter screens out results meeting the following attributes: LDAP entries of type objectClass=person. LDAP entries that are members of the faculty group.
Group Authentication	Optional. You can enable it to verify whether the query result belongs to a certain group.
Group Type	Optional. Available only if Group Authentication enabled. The Group Type depends on the schema of the LDAP directory. If the directory is Active Directory (AD), use Windows-AD as the group type; If the directory is OpenLDAP, use OpenLDAP as the group type.
Group DN	Optional. Available only if Group Authentication enabled. For example, setting it to cn=faculty,ou=Groups,dc=uex,dc=edu means that if the user is not a member of the faculty group, authentication will fail, even if their username and password are correct.
Secure Connection	Enable this to encrypt the connection to the LDAP server, ensuring secure communication.
Protocol	Select which secure LDAP protocol to use, either LDAPS: It uses SSL for encryption. LDAPS connection starts directly with TLS (secure from the start). STARTTLS: It is a command that upgrades an existing, unencrypted connection to a secure, encrypted connection using Transport Layer Security (TLS). STARTTLS connection starts unencrypted, then upgrades to TLS. It has potential exposure before encryption starts, but it has the flexibility to work with servers that support both encrypted and unencrypted communication. The option appears only when Secure Connection is enabled.
Certificate	To initiate the secure connection, the LDAP server sends its certificate to FortiWeb during the TLS handshake. FortiWeb checks if the certificate is signed by a trusted CA using the CA certificate you've selected here (This certificate is uploaded through the Admin Cert Local tab in System > Admin > Certificates. Verification Options With CA Certificate Selected: FortiWeb performs certificate verification. The LDAP server's address (IP or FQDN) must be in the Subject Alternative Name (SAN) field of the server certificate. Ensures the LDAP server's identity is verified. Without CA Certificate (leave this option empty): FortiWeb accepts any certificate from the LDAP server. This effectively disables certificate verification. The TLS connection is encrypted but not validated. Only available when Secure Connection is enabled.

4. Click OK.

   If you want FortiWeb to retrieve user attributes and forward them to the back-end server, click Create New to add attributes. For details, see Step 4: Optional: Configure forwarding of LDAP user attributes.

5. Go to Application Delivery > Site Publish > Authentication Server Pool.
6. Click Create New, enter a name for the pool. Use "University Portal LDAP server pool".
7. Click Create New and complete the following settings:

8. Authentication Validation Method	LDAP.
   LDAP Server or RADIUS Server	Select "University Portal LDAP".
   RSA SecurID	Not applicable to LDAP server.

9. Click OK.

Step 3: Configure a site publish policy for University Portals

Create site publish rules to handle user authentication:

• Specify the LDAP server information and choose the authentication method.

• Enable SSO functionality, allowing users to access https://students.uex.edu and https://faculty.uex.edu without re-authenticating.

Perform the following steps:

1. Go to Application Delivery > Site Publish > Site Publish and select the Site Publish Rule tab.
   
2. Click Create New and configure the settings.

Name	University Portal Or enter any name that can help you distinguish this Site Publish rule.
Published Site Type	Regular Expression
Published Site	(students|faculty).uex.edu$ This will match both students.uex.edu and faculty.uex.edu
Path	/ To perform user authentication for all paths under the published site, enter a forward slash /.
Cookieless	Disable. If you want to implement SSO, this option should be disabled. FortiWeb stores authentication information in cookies for automatic login to SSO sites.
Client Authentication Method	This specifies how the authentication process is performed. The following methods are applicable to LDAP: HTML Form Authentication FortiWeb presents an HTML form to collect user credentials, which are then validated against an LDAP server. The process works as follows: FortiWeb presents an HTML form for user input. It typically includes input fields for credentials. It can be styled to match your website's design. The default authentication pages are located in System > Config > Replacement Message. For detailed instructions on editing authentication pages, refer to "Customizing error and authentication pages (replacement messages)" in the FortiWeb Administration Guide. User submits credentials via the form. FortiWeb sends these credentials to the LDAP server for validation. If valid, FortiWeb creates an authentication cookie for the session. HTML Basic Authentication When using this approach: FortiWeb responds to the client browser with a 401 (Unauthorized) status code. The browser displays its built-in authentication prompt. It typically appears as a small pop-up window or overlay. User enters credentials. FortiWeb validates these credentials against the LDAP server.
Log Off Path Type	Optional.
Published Server Log Off Path	Optional. Enter /logout if user logs off through https://students.uex.edu/logout. FortiWeb uses this path to recognize when a user has logged out, allowing it to: Invalidate the user's authentication session. Prompt for re-authentication on subsequent access attempts to protected resources.
Redirect URL After Authentication (Optional)	Optional. Specify a URL to redirect users to it after successful authentication, for example, /dashboard. Note: Ensure that this value is a sub-path of the Path field configured above. For example, if the Path field is set to /, entering /dashboard here is valid because /dashboard is a sub-path of /. Incorrect Example: If the Path field is set to /library and /dashboard is entered here, it will result in a conflict. Correct Example: To fix this, set the value to /library/dashboard, ensuring it aligns as a sub-path of /library.
Authentication Cookie Timeout	FortiWeb stores user credentials in authentication cookies for automatic login to SSO sites. The Authentication Cookie Timeout option allows you to specify the length of time (in minutes) before the authentication cookie expires, requiring the client to re-authenticate. The default value is 0, which means the browser only deletes the cookie when the user closes all browser windows. You can adjust this value according to your security requirements and user experience preferences. Valid values are from 0 to 216000 minutes.
Authentication Server Pool	Select the server pool "University Portal LDAP server pool".
Authentication Delegation	No Delegation This means no authentication is required between FortiWeb and the back-end servers.
Append Custom Header	Optional Enable this option to forward the username to the back-end server in HTTP header. This is useful in scenarios where back-end servers rely on receiving the username in the HTTP request to associate the session with a specific user, or to allow the application to directly recognize the authenticated user and deliver personalized content or services. Refer to Step 4: Optional: Configure forwarding of LDAP user attributes.
SSO Support	Enable
SSO Domain	.uex.edu After FortiWeb authenticates the client for either students.uex.edu or faculty.uex.edu, the client can access the other without authenticating a second time.
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).

3. Click OK.
4. Go to Application Delivery > Site Publish > Site Publish and select the Site Publish Policy tab.
5. Click Create New.
6. In Name, enter "University Portal Policy".
7. Enable the following:
   • Account Lockout: Restricts the number of failed login attempts before the account is locked to prevent unauthorized access.
   • Limit Concurrent Users Per Account: Limits the number of simultaneous logins allowed for a single account to enhance security and prevent account sharing. It only takes effect if the Client Authentication Method is HTML Form Authentication.
   • Credential Stuffing Defense: Leverages FortiGuard's Credential Stuffing Defense database to detect and block credential stuffing attacks.
     
8. Click Create New and in Rule, select the name of the site publishing rule.
   
9. Click OK.

Step 4: Optional: Configure forwarding of LDAP user attributes

FortiWeb supports retrieving user attributes from the LDAP server and forwarding them to the back-end server. This feature is useful for scenarios where the back-end server needs detailed user information to achieve granular user management, such as rendering resources based on the user's role.

Step 4.1: Specify the attributes to be retrieved

In the LDAP Server settings, specify the attributes to be retrieved from the LDAP server.

1. Go to User > Remote Server and select the LDAP Server tab.
2. From the LDAP server table, select the "University Portal LDAP" server.
3. In the Extracted Attributes section, click Create New to add attributes.
4. Configure the following:

   Name	FortiWeb supports retrieving up to 16 attributes from the LDAP server. Choose from the predefined names. This name will serve as a reference in the Site Publish rule. The actual attribute name should be specified in the Attribute Name field below.
   Attribute Name	Specify the name of the attribute you want FortiWeb to retrieve, for example, "email".

5. Click OK.

Step 4.2: Reference the attribute in a site publish rule

Specify the attributes in a site publish rule, so that FortiWeb can insert custom headers to carry the corresponding attributes in the packets sent to back-end servers.

1. Go to Application Delivery > Site Publish > Site Publish and select the Site Publish Rule tab.
2. From the Site Publish Rule table, select the rule "University Portal".
3. Enable the Append Custom Header option.
4. Click OK.
5. In the Custom Headers section, click Create New.
6. Configure the following:

   Custom Header Name

   Enter a name for the HTTP header. For example, "LADP-email".

   Custom Header Value Format

   Specify the format of the header value. For example, if in the LDAP server settings you have created an attribute pair like "ATTRIBUTE1: email", you can reference the value of the email attribute using the variable $LDAP.ATTRIBUTE1. This will retrieve the email value and use it as the custom header value. You can also customize the format by adding a prefix or suffix, such as fwb-$LDAP.ATTRIBUTE1-ldap. For more details, refer to LDAP attribute retrieval example

7. Click OK.
8. Repeat the steps above to add more headers.

LDAP attribute retrieval example

If you want FortiWeb to extract the value of the Email attribute and forward it as an HTTP header in the packet to the back-end server, configure the following settings.

In LDAP server, add the following attribute:

Name	ATTRIBUTE1
Attribute Name	Email

In Site Publish rule, add the following custom header:

Custom Header Name	LDAP-Email
Custom Header Value Format	$LDAP.ATTRIBUTE1

When FortiWeb receives a request from a client, it will retrieve the "Email" attribute of this user from the LDAP server (assuming it is "Email:user1@example.com"), then forward the following HTTP header to the back-end server:

LDAP-Email:user1@example.com

Next step

Apply the site publish policy to web protection profile and then reference the profile in a server policy. See:

• Configuring a protection profile for inline topologies

• Configuring an HTTP server policy

Conclusion

In this scenario, FortiWeb integrates with an LDAP server to authenticate users accessing protected applications. Filters and group settings in FortiWeb allow fine-grained access control, ensuring users are authenticated based on their roles or organizational units (e.g., faculty or student). This setup simplifies administration, enhances scalability, and improves security by centralizing identity management and reducing reliance on local accounts.