Authentication types
The following types of authentication are supported:
- Basic authentication
- NTLM authentication
- Kerberos authentication
- Form-based authentication
- SAML-SP authentication
- Auth-User authentication
- Certificate authentication
Basic authentication
For basic authentication, the browser encodes the user name and password in the “Proxy-authorization” header using the base64 encoding scheme. The FortiProxy unit starts two LDAP transactions:
- The first bind is to validate the user with the user name and password.
- The second transaction is to query the user’s group information.
If the first bind fails, the FortiProxy unit challenges the browser again to let the user enter the correct user name and password.
Most browsers carry the “Proxy-authorization” header unsolicited in the following request to prevent further challenges until the browser is closed.
The basic method uses nearly plain text to convey the user name and password. To protect sensitive information, use the FortiProxy secure web authentication portal in the HTTPS tunnel.
NTLM authentication
Because basic authentication directly conveys the password, it could reduce the authentication security. NTLM authentication fixes this problem by avoiding sending the password directly. The client sends one request, the authenticator sends back one random number, and the client sends back the user name and hash value (computed with the user’s password and a random number) to the authenticator. The authenticator keeps the user’s password and compares the hash value with the same computing method.
There are two type of NTLM authentication:
- Agent-based NTLM authentication
- Agentless NTLM authentication
Agent-based NTLM authentication
In agent-based NTLM authentication, a Collector agent, such as FSSO Collector or FortiAuthenticator, acts as the NTLM authenticator (the Collector agent uses the domain controller NTLM service through the API). The FortiProxy unit bypasses the NTLM messages. In the following figure, “FTNT” means the private communication protocol between the FortiProxy unit and the Collector agent. After the Collector agent authenticates the user successfully, it also sends back the user’s group information. In this method, it requires the Collector agent and uses the single connection, which could become a performance bottleneck. The agentless NTLM method tries to fix this problem.
Refer to the following example for more details: Using single sign-on with the FSSO agent.
Agentless NTLM authentication
In agentless NTLM authentication, the FortiProxy unit communicates with the domain controller directly using the SMB protocol. The FortiProxy unit uses multiple concurrent connections and supports multiple domain controllers to scale up. After the user is authenticated, another LDAP group query is performed. This method still needs to communicate with the authenticator (domain controller). The Kerberos method can eliminate this kind of communication to further improve performance.
Refer to the following examples for more details:
Kerberos authentication
When the FortiProxy unit challenges the browser with the “negotiate” method, it means that Kerberos is preferred, and NTLM can still be compatible with the “negotiate” method (the FortiProxy unit can be configured to accept this fallback or not). The browser requests the service ticket using the Key Distribution Center (KDC). If the browser can get the ticket (that is, the user logon information for the domain), the browser sends back the ticket with the authorization header, user name, and Privileged Attribute Certificate (PAC) data ciphered in the ticket. This service ticket is cached in the client, and the default renewal time is 10 hours. The FortiProxy unit extracts the user name after deciphering the ticket (with the configured keytab file) and queries the user’s group. There is no communication with the authenticator, which can help scale up the deployment. The FortiProxy unit still needs to communicate with the LDAP server. For more information about PAC usage, see PAC data.
Refer to the following examples for more details:
Form-based authentication
Form-based authentication is very similar to basic authentication. The browser receives one login page, such as the widely used public WiFi access disclaimer page. After the user enters the user name and password and clicks the login button, the user name, password, and original URL are posted to the FortiProxy unit. Form-based authentication has the same security issue with a plain-text user name and password. Fortinet recommends using the secure authentication portal to improve the security.
Refer to the following example for more details: Setting up a form-based authentication captive portal using SSL certificate.
SAML-SP authentication
Security Assertion Markup Language(SAML) is an XML-based, open-standard data format for exchanging authentication and authorization data between two security domains: an Identity Provider (IdP) and a Service Provider (SP). The FortiProxy unit natively supports the SAML protocol and will act as a Service Provider. In SAML-SP authentication, the FortiProxy unit redirects u-authenticated users to the IdP, which could be Okta Identity, Microsoft ADFS, FortiAuthenticator, or Google SSO for authentication. After the user is authenticated with the IdP, the user is redirected to the FortiProxy unit with SAML assertion information using the POST method. The assertion information includes the authentication result, user name, and group in attribute assertions (or claim in term of ADFS). Based on that information, the FortiProxy unit executes both authentication and authorization (matching the user to the group). If the IdP is Microsoft ADFS, the FortiProxy unit supports resolving the user group information through the LDAP query with Kerberos or NTLM authentication.
|
In the figure above, the 2.1 flow and 2.2 flow are the communication between the browser and the IdP for authentication with any authentication method (form-based authentication is mostly used). If the communication goes through the FortiProxy unit, a firewall policy should be created to explicitly allow the communication without user and group enforcement. |
Refer to the following examples for more details:
Auth-User authentication
In network security, X-AUTH-USER user represents a custom header used within an HTTP authentication scheme where a client is expected to supply a username and a corresponding key or token. This key could manifest as an API key, an encrypted password, or a token provided by an authentication service.
Unlike basic authentication, which relies on a standard authorization header with base64-encoded credentials, X-AUTH-USER affords a more versatile approach. It accommodates additional fields and adapts to current security paradigms by aligning with methods such as API keys or OAuth tokens. This flexibility allows it to conform to various authentication workflows and to cater to diverse security requirements, offering a customized solution over traditional authentication headers.
The following figure illustrates a Auth-User authentication setup with two FortiProxy units where FPX2 manages authentication and FPX1 handles authorization. On FPX2, the user's credentials are scrutinized and authenticated using protocols like basic, NTLM, or Kerberos. Once the user is authenticated, FPX2 appends the X-Authenticated-User header to the HTTP request to the upstream proxy FPX1, which then leverages the data within the X-Authenticated-User header to perform authorization, contrasting the username with existing access policies and user group data to ascertain suitable access privileges.
The X-Authenticated-User header allows FPX1 to implement Single Sign-On (SSO) for incoming traffic from FPX2 and eliminates the need for repeated authentication by the user. This setup guarantees a seamless operation where FPX2 is dedicated to user authentication while FPX1 enforces resource access control based on the authentication data relayed by FPX2, ensuring that user identities are precisely and securely communicated between the proxies for secure access control.
Refer to the following example for more details: Configuring X-Auth-User authentication.
Certificate authentication
Certificate authentication, often referred to as Cert Auth, is a secure authentication method where FortiProxy validates clients accessing protected network resources using digital certificates, which are verified credentials issued by a trusted Certificate Authority (CA). Certificate authentication provides a strong form of identity verification using cryptographic proof rather than knowledge of secrets, such as passwords.
When a client attempts to access a resource, as part of the SSL/TLS handshake process, FortiProxy requests a digital certificate to serves as the client's identity for the session. FortiProxy then performs validation checks to confirm the certificate's legitimacy, ensuring that the certificate is issued by a trusted CA and not expired or revoked. If the validation passes, FortiProxy further determines access permissions by extracting the user identity embedded within the certificate, such as the user's name. No additional authentication mechanisms are needed as the certificate includes sufficient information to establish the client's identity. In cases where resources are restricted to certain groups, FortiProxy queries an LDAP server to retrieve the user's group memberships to enforce access control policies.
The certificate remains valid for the duration of its configured lifespan. To maintain security, FortiProxy supports certificate revocation checks through CRLs or OCSP, which ensures that the presented certificates are still valid and have not been compromised or revoked after issuance.
Refer to the following example for more details: Setting up an authentication captive portal using client certificate 7.2.8.