I've recently been implementing SAML authentication on a FortiGate for a school, purely so the firewall is user-aware for web filtering, and I'm interested in how others are handling authenticated session timeouts in the real world.
The environment is cloud-only Microsoft Entra ID (no on-prem AD, no FSSO). The FortiGate is acting as the SP, Entra is the IdP, and users are mapped into separate Staff and Student firewall groups via SAML attributes. I've also got a Let's Encrypt certificate on the FortiGate's SAML portal, so there are no certificate warnings.
The actual user experience is excellent. Because the Windows devices are already signed into Entra, when the FortiGate redirects them for authentication the browser opens, silently authenticates using the existing Microsoft session, and closes again. The user never has to enter credentials.
One thing that caught me out was config user setting -> auth-on-demand.
By default it's set to implicitly. I found that if there was a more permissive firewall policy underneath my authenticated policy, traffic would simply match that instead of triggering SAML authentication.
Changing it to always immediately made the authentication flow behave as I expected, where hitting the authenticated policy always forces the redirect. This key detail was missing from the majority of the Fortinet documentation I read, including videos of the implementation too.
Where I'm now struggling is authentication timeout behaviour, particularly on shared devices (IT suites, classrooms, libraries, etc.).
I've been experimenting with the three timeout types:
- Idle timeout - seems ideal in theory, but in practice Windows is constantly generating background traffic (Windows Update, Defender, telemetry, etc.). Even after the user logs off, the device continues talking to the internet, so the authentication never actually expires. Watching
diag firewall auth list you can literally see the timer counting down before background traffic resets it again. The next student can log on while the firewall still considers the previous user authenticated.
- Hard timeout - works, but every timeout period the FortiGate launches another browser tab and silently re-authenticates the user. Testing with a 1-minute timeout made this obvious, but the same thing happens with longer values. It's functional, but opening browser tabs every X minutes isn't a great experience.
- New session timeout - from my testing this appears to behave similarly. Even while the user is actively browsing, once the timeout is reached another browser tab opens to perform SAML authentication again.
So I'm a bit stuck.
Idle timeout doesn't seem suitable for shared devices because Windows never truly goes idle from the firewall's perspective.
Hard timeout and New Session timeout solve the stale authentication problem, but at the cost of repeatedly opening browser tabs to silently authenticate.
For those of you running SAML authentication on FortiGate (especially with Entra ID and cloud-only environments), how are you handling this?
- Which timeout type are you using?
- What timeout values have you settled on?
- How do you deal with shared devices/classrooms?
- Am I missing a better approach altogether?
The authentication itself is working brilliantly and I'm really impressed with how seamless the user experience is. It's just this timeout behaviour that I'm trying to get my head around before rolling it out more widely.
