Centralized user authentication with IdP integration

A healthcare provider operates an online management system that includes:

• Doctor portal (https://ehr.healthcare-system.com) for accessing medical records, treatment plans, etc.

• Internal Communication Portal (https://intranet.healthcare-system.com) to facilitate communication between doctors, nurses, and administrative staff.

Due to legacy practices, default administrator accounts with unchanged passwords are still active, and unnecessary user accounts remain in the system, posing a significant security risk. These vulnerabilities expose the system to potential unauthorized access, risking sensitive patient data.

The healthcare provider wants to integrate an IdP system to:

• Authenticate users securely. Enforce minimum password complexity. Mandate periodic password changes for all users.

• Enable SSO across all university portals.

• Enforce Multi-Factor Authentication (MFA) for high-risk users, such as administrators.

The healthcare provider also wants their Web Application Firewall (WAF) (e.g., FortiWeb) to seamlessly integrate with the IdP to protect their applications and facilitate secure access.

Solutions by FortiWeb

Identity Providers (IdPs) are becoming increasingly popular due to their ability to address modern authentication and access control needs in a secure, scalable, and user-friendly manner.

If you are adopting an Identity Provider (IdP) or already have one in your infrastructure, FortiWeb can be deployed in front of your web servers and configured to delegate authentication to the IdP.

Key benefits of integrating FortiWeb with an Identity Provider (IdP) for delegating user authentication

Using FortiWeb to integrate with an Identity Provider (IdP) for delegating user authentication offers significant advantages by combining FortiWeb’s robust web application security features with the advanced authentication capabilities of the IdP:

• Broad IdP Compatibility: FortiWeb supports SAML- and OAuth-based IdP systems like Okta, Azure AD, Ping Identity, Google, Facebook, and more, enabling smooth deployment without requiring major changes to your existing infrastructure.

• Enhanced Security: FortiWeb prevents attacks such as SQL injection, cross-site scripting (XSS), and malicious bot activity, ensuring only clean, secure traffic reaches your back-end servers.

• Seamless Support for SSO and MFA: FortiWeb fully supports Single Sign-On (SSO) and Multi-Factor Authentication (MFA), ensuring that the IdP system’s functions remain fully operational and uncompromised when integrated with FortiWeb.

• Credential-Free Management: FortiWeb does not store or manage user credentials, reducing administrative overhead and minimizing security risks.

• Enabling Role-Based Access Control (RBAC): FortiWeb can retrieve user attributes (e.g., emails, usernames) included in SAML assertions or OAuth tokens from the IdP and forward them to the back-end server, enabling precise and efficient access control.

The following outlines the authentication process involving the client, FortiWeb, and the IdP.

• User Attempts to Access a Portal:

  • A Doctor navigates to https://ehr.healthcare-system.com.

  • The DNS directs the request to FortiWeb.

• FortiWeb Redirects to the IdP:

  • FortiWeb checks its server policy and identifies that the user is not authenticated.

  • FortiWeb redirects the user’s browser to the IdP’s login page (e.g., https://idp.ehr.healthcare-system.com).

• IdP Authenticates the User:

  • The doctor logs in to the IdP using their credentials.

  • If MFA is enabled, the IdP requires an additional authentication step, such as entering an OTP.

• IdP Issues a SAML Assertion:

  • The IdP validates the user’s credentials and issues a SAML assertion containing the user’s identity and attributes (e.g., name, role, group).

• FortiWeb Receives the Assertion:

  • The browser sends the SAML assertion to FortiWeb’s Assertion Consumer Service (ACS) Path (e.g., https://ehr.healthcare-system.com/sso/saml/acs).

  • FortiWeb validates the assertion using the IdP’s public certificate.

• Traffic Inspection by FortiWeb:

  • After authentication, FortiWeb inspects the user’s HTTP/HTTPS requests for potential threats (e.g., SQL injection, XSS).

  • Safe traffic is forwarded to the backend doctor portal server.

• Access Granted:

  • The doctor is granted access to the doctor portal.

  • If the doctor later accesses the Internal Communication Portal (https://intranet.healthcare-system.com), SSO in IdP ensures they don’t need to log in again.

Configurations on FortiWeb

• Step 1: Adopting an IdP system

• Step 2: Configuring a SAML server pool

  • Step 2.1: Configuring a SAML server

  • Step 2.2: Adding SAML servers to a SAML server pool

  • Step 2.3: Configuring the IdP Login Page replacement message

• Step 3: Creating a site publish rule

Step 1: Adopting an IdP system

The Identity Providers (IdPs) available in the market are typically SAML-based (e.g., Okta, Azure AD, Ping Identity) or OAuth-based (e.g., Google, Facebook). FortiWeb supports both types.

In the configuration examples below, we assume the use of a SAML-based IdP.

Configuration details for the OAuth-based IdP are not covered here. For more information, refer to the "OAuth authorization and OIDC authentication" section in FortiWeb Administration Guide.

Step 2: Configuring a SAML server pool

Configuring a SAML server in FortiWeb allows it to function as a Service Provider (SP), delegating authentication to a trusted Identity Provider (IdP). The configuration includes specifying the Entity ID and Service Path to identify the SAML server, along with detailed settings such as paths for the Assertion Consumer Service (ACS) and Single Logout Service (SLO), which play crucial roles in the authentication process.

The process involves the following steps:

1. Configure one or more SAML servers.
2. Add SAML servers to a SAML server group.
3. Configure the SAML Login Page replacement message to customize the IdP names shown on the SAML login page.

Please check with your IdP to confirm whether it supports Single Sign-On (SSO) and Multi-Factor Authentication (MFA). If these features are supported and configured in your IdP, FortiWeb will automatically integrate them into the authentication process. No additional settings are required on FortiWeb to enable these features.

Step 2.1: Configuring a SAML server

1. 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.
   
2. Click Create New and complete the following settings:
   

   Name	Enter a name for the SAML server that can be referenced by other parts of the configuration. The maximum length is 63 characters.
   Entity ID	This is a unique identifier for the SAML Identity Provider (IdP). It is used by FortiWeb to recognize the IdP during SAML communication. For example, https://idp.example.com/saml
   Service Path	This defines the base URL for all SAML-related services, such as login and logout. Combined with the protected hostname, it helps create consistent SAML endpoints. The value of the Service Path can be set to, for example, /sso/saml/, which serves as the base path for various SAML services. Combined with specific service endpoints, it forms a series of SAML service paths. For example: Metadata: /sso/saml/metadata SSO Initiation: /sso/saml/login ACS Path: /sso/saml/acs SLO Path: /sso/saml/slo During the authentication process, service-related requests are sent to the service paths in FortiWeb, such as the Assertion Consumer Service (ACS) Path. For example: After a client is authenticated by the IdP, the SAML assertion is sent to FortiWeb’s ACS Path (e.g., https://ehr.healthcare-system.com/sso/saml/acs). FortiWeb processes this assertion at the ACS endpoint by validating its signature and other attributes to determine if the client is authorized to access the requested resource.
   Signing Enforcement	Enable to enforce signing verification to digitally sign the SAML message, and then the Identity Provider will verify the signature to confirm its integrity.
   Assertion Consumer Service
   Binding Type	The available binding type is POST, where the SAML assertion is sent via an HTML form submission using base64-encoded data. This is the most commonly used method due to its compatibility and ability to handle larger payloads securely.
   Path	This is the endpoint on FortiWeb that receives SAML assertions from the IdP after user authentication. Its default value is service-path/acs. For example, if the Service Path you have set above is /sso/saml/, the default path for the Assertion Consumer Service (ACS) will be /sso/saml/acs. If you prefer a custom name, you can specify a different path in this option. Combined with the protected hostname, it forms the complete ACS URL, such as https://example.com/sso/saml/custom-acs. After successful authentication, the client sends the SAML assertion to the ACS URL. FortiWeb processes the assertion to authenticate the user and grant access to the requested resource.
   Single Logout Service
   Binding Type	Specifies the binding method used for the Single Logout (SLO) request. POST—SAML protocol messages are transported via the user's browser in an XHTML document using base64-encoding. REDIRECT—The logout request or response is carried in the URL of an HTTP GET request. This is commonly used for initiating logout as it is lightweight and fast, but it is best suited for shorter messages.
   Path	This is the endpoint on FortiWeb for handling logout requests or responses. For example: /sso/saml/slo. Its default value is service-path/slo. For example, if the Service Path you have set above is /sso/saml/, the default path for the Single Logout Service (SLO) will be /sso/saml/slo. If you prefer a custom name, you can specify a different path in this option. Combined with the protected hostname, it forms the complete SLO URL, such as https://example.com/sso/saml/custom-slo. When a user logs out from one application, the SLO URL ensures the user is logged out across all federated applications by sending a logout request to the Identity Provider (IdP).
   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 Centralized user authentication with IdP integration below will populate. The metadata file typically includes the IdP's public certificate, along with other important information about the Identity Provider (IdP), such as its Entity ID, Single Sign-On (SSO) URL, and Single Logout (SLO) URL. The public certificate contained in the metadata is specifically used by FortiWeb to verify the digital signature of the SAML assertion sent by the client, ensuring that the assertion was indeed issued by the trusted IdP. The metadata file is provided by the Identity Provider such as AD FS 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 Centralized user authentication with IdP integration is valid.

3. Click OK.
4. Click Create New to add domain names for this server. When users log in with an email address suffixed with the specified domain name, the authentication request will be forwarded to this SAML server.
   For instance, if the user doesn't select an IdP in the drop-down list, instead, they enter "xxx@example.com" in the Email field, FortiWeb will forward the request to the SAML server which is configured with the domain name "example.com".
   
   You can add multiple domain names for one SAML server. Similarly, it's allowed to associate multiple SAML server with the same domain name.
5. Click OK.

Step 2.2: Adding SAML servers to a SAML server pool

1. Go to Site Publish > SAML Server Pool.
   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.
   
2. Click Create New.
3. Enter a name for the SAML server pool that can be referenced by other parts of the configuration. The maximum length is 63 characters.
4. Click OK.
5. Click Create New to add a new SAML server.
6. Enter a name for the server. Please enter an appropriate name, as FortiWeb will extract this name and display it on the login page shown to your users.
7. Select the SAML Server you have created in the SAML Server tab of the User > Remote Server page.
8. Click OK. Repeat the steps above if you want to add multiple SAML servers.

Step 2.3: Configuring the IdP Login Page replacement message

When FortiWeb redirects the client to IdP for login, for example, redirecting client to https://idp.example.com/saml/login, it displays an IdP login Page. You can edit the information to be displayed on this page.

1. Click Generate Login Form above the SAML server table.
   
2. FortiWeb extracts the value of the "SAML Server Name" and then generates a SAML login page accordingly as shown below. You are allowed to change the IdP name in the drop-down list by editing the code in the right pane.
   
3. Click Apply to.
4. Select the Replacement Message you want to apply this SAML Login Page to. The Replacement Message can then be referenced in a server policy. Ensure that this Replacement Message and the web protection profile containing the corresponding site publish rule are applied to the same server policy.
5. Click OK. Please note that if you add more SAML servers in the future, remember to regenerate the SAML Login Page and then apply.
6. You will see this SAML Login Page in System > Config > Replacement Message.
   
   

Step 3: Creating a site publish rule

1. Go to Application Delivery > Site Publish > Site Publish and select the Site Publish Rule tab.
   
2. 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	Regular Expression
Published Site	Enter ^.*\.healthcare-system\.com. This will match both ehr.healthcare-system.com and intranet.healthcare-system.com. Alternatively, you can create two separate site publish rules for these addresses, setting the Published Site to ehr.healthcare-system.com in one rule and intranet.healthcare-system.com in the other, then reference these two rules in a Site Publish policy.
Path	To perform user authentication for all paths under the published site, enter a forward slash /. To restrict authentication to specific paths, such as ehr.healthcare-system.com/patient-record/, enter the desired path (e.g., /patient-record/). Including or omitting the trailing / does not affect functionality, as both configurations cover subpaths like ehr.healthcare-system.com/patient-record/david.
Cookieless	Disable. Cookies are used for storing and managing user credentials when FortiWeb handles user authentication directly instead of delegating it to an IdP. In the case of IdP integration, user credentials remain a "black box" to FortiWeb. FortiWeb does not parse or manage user credentials but relies on the assertion provided by the IdP to accept or deny access. This makes cookies unnecessary for this purpose. Therefore, this option is not applicable in scenarios involving IdP integration.
Client Authentication Method	SAML Authentication
Log Off Path Type	Optional. If you want to redirect users to a specific page after they log off. In this example, we assume you want to show ehr.healthcare-system.com/logout when users log off. Select Simple String.
Published Server Log Off Path	Enter /logout. 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 /logout here is valid because /logout is a sub-path of /. Incorrect Example: If the Path field is set to /patient-record and /logout is entered here, it will result in a conflict. Correct Example: To fix this, set the value to /patient-record/logout, ensuring it aligns as a sub-path of /patient-record.
Redirect URL After Authentication (Optional)	Specify a URL to redirect users to it after successful authentication., for example, /dashboard. After successful authentication, FortiWeb redirects the user to the specified URL instead of the original requested URL. The same rule applies as with the Published Server Log Off Path: ensure that the specified URL is a sub-path of the Path field configured above.
SAML Server Pool	Select the SAML server pool that you have configured in Step 2.
Authentication Delegation	Kerberos Constrained Delegation With Kerberos Constrained Authentication (KCD), FortiWeb obtains a Kerberos service ticket for the specified web application on behalf of the client, and then forward or delegate the authentication to the back-end server. It adds the ticket to the HTTP Authorization: header of the client request with Base64 encoding. If KCD is selected, you will need to take additional steps such as uploading a Keytab file, configuring a Service Principal Name (SPN) pool, and other related configurations. For detailed instructions, refer to the sections "Creating an Active Directory (AD) User for FortiWeb - Keytab File" and "Using Kerberos Authentication Delegation" in the FortiWeb Administration Guide. No Delegation This means no authentication is required between FortiWeb and the back-end servers. We recommend using this method if you are confident in the security of the traffic from FortiWeb to the back-end servers.
Append Custom Header	Enable to retrieve user attributes (e.g., emails, usernames) included in SAML assertions or OAuth tokens from the IdP and appends it as an HTTP header to the packet forwarded to the back-end server. For instance, appending username in the header allows the back-end server to associate the session with a specific user. This is optional.
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. If you want FortiWeb to forward certain headers to the back-end server, click Create New to define the headers.

   Custom Header Name

   Enter a name for the HTTP header. Special characters are not supported.

   Custom Header Value Format

   The following variables are supported in the value: $USERNAME: This is a predefined variable. FortiWeb will extract the username attribute of the user from the authentication server. $RAWNAME: This is a predefined variable. It's useful when sending the email attribute to back-end servers. Using $RAWNAME will send the whole email address such as example@abc.com, while using $USERNAME will only send the former part example. $LDAP.ATTRIBUTE{n}: This is a series of custom variables specific to LDAP servers. It is not applicable in this scenario as it does not apply to IdP integration. These variables only take effect when FortiWeb is directly connected to an LDAP server for authentication. FortiWeb will look up the value of the corresponding attribute and populate it in the HTTP header.

5. Click OK.
6. Go to Application Delivery > Site Publish > Site Publish and select the Site Publish Policy tab.
7. Click Create New.
8. In Name, type a unique name that can be referenced in other parts of the configuration. The maximum length is 63 characters.

   Note: Under the Name field, you will see toggle buttons for Account Lockout, Limit Concurrent Users Per Account, and Credential Stuffing Defense. These features do not need to be enabled, as they will not take effect with IdP integration. Since FortiWeb does not manage user credentials in this setup, it cannot perform these checks.

9. Click Create New and in Rule, select the name of the site publishing rule.
   
10. Click OK.

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

By leveraging FortiWeb as a reverse proxy, you not only reduce configuration effort with the back-end servers but also enhance the security, compliance, and operational efficiency of your web application infrastructure.