1 Solution
You can add a user/group into source of a firewall policy for a VIP object, and it will present the usual captive portal on the VIP's port before permitting access:
Naturally, this will also provide 2FA, if configured.
The caveat is that this still behaves like regular FortiGate captive portal: The authentication is IP-based (~anybody who shares the public IP with an authenticated client will also have access), and has a default 5-minute idle timeout (no packets -> start ticking). No cookies.
If your scenario cannot tolerate these limitations, I believe FortiWeb would be a better match for a more proper login flow, see e.g. https://docs.fortinet.com/document/fortiweb/7.2.0/administration-guide/111789/authentication-styles .
You can add a user/group into source of a firewall policy for a VIP object, and it will present the usual captive portal on the VIP's port before permitting access:
Naturally, this will also provide 2FA, if configured.
The caveat is that this still behaves like regular FortiGate captive portal: The authentication is IP-based (~anybody who shares the public IP with an authenticated client will also have access), and has a default 5-minute idle timeout (no packets -> start ticking). No cookies.
If your scenario cannot tolerate these limitations, I believe FortiWeb would be a better match for a more proper login flow, see e.g. https://docs.fortinet.com/document/fortiweb/7.2.0/administration-guide/111789/authentication-styles .
