Authentication types
The following types of authentication are supported:
- Basic authentication
- NTLM authentication
- Kerberos authentication
- Form-based authentication
- SAML-SP 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.
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.
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.
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.
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 something else 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.
NOTE: In the preceding figure, 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.
The following is an example of a SAML configuration:
For more information, check the following references: