How to set login / time restriction on FortiAP Captive Portal when configured with SAML?

[Anand_Narayana]

I have integrated the Wireless Captive Portal to SAML on O365. When I try to access any URL, it redirects to login.microsoftonline.com and entering the O365 ID, able to get connected to the wireless and access Internet. The problem that I am facing is outlined below and would need a suggestion to resolve.

1.  Existing user is removed from O365 group and I am still able to get connected to the wireless and access Internet without any prompt for a user login (since the ID is now removed from O365 group, it should ask for a login prompt)
2. Rebooting the laptop, I am still able to get connected to the wireless and access Internet without prompt for a login to O365
3. Also how to set a timelimit when using the O365 (SAML). I am aware of using the Guest Management that uses local authentication but need assistance / advise when using SAML

To resolve this, I should Disassociate the user in the controller (i.e. FortiGate -> WiFi & Switch Controller -> WiFi Client) and then it prompt to enter the O365 credentials to get connected to the wireless and access Internet.

[Markus_M]

Hello Anand,

on which device is the SAML IdP configured to be used? On the FAP directly, or on the FGT?

The FGT may see your user paired as username and IP in the firewall user monitor. If that is matched, the FGT will not ask for authentication of this device.

With SAML only, the respective user should be able to pass authentication with a valid cookie. From the IdP you might be able to set a cookie validity period after which a re-authentication must occur.

Best regards,

Markus

[Anand_Narayana]

SAML (Azure) configuration is on the FortiGate CLI configuration. When the user selects the Wireless SSID, it opens the web browser redirecting to login.microsoftonline.com for authentication (since SAML is configure) and once the login is successful, user will be able to connect to the wireless access Internet.

So for my requirement, where do I adjust the cookie validity period or any suggestions for an alternate?

Sample configuration

config user saml
edit "Guest_Wifi"
set cert "wildcard_xxxx"
set entity-id "https://10.1.1.254:1000/remote/saml/metadata"
set single-sign-on-url "https://10.1.1.254:1000/remote/saml/login"
set single-logout-url "https://10.1.1.254:1000/remote/saml/logout"
set idp-entity-id "https://sts.windows.net/xxxxxxxxxxxxxx/"
set idp-single-sign-on-url "https://login.microsoftonline.com/xxxxxxxxxxxxx/saml2"
set idp-single-logout-url "https://login.microsoftonline.com/comm?wa=wsignout1.0"
set idp-cert "Azure_Guest-Wireless"
set user-name "username"
set group-name "group"
next
end

config user group
edit "Guest_Wi-Fi"
set authtimeout 2
set member "Guest_Wifi"
config match
edit 1
set server-name "Guest_Wifi"
set group-name "xxxxxxxxxxxxxxxx"
next
end
next
end

config wireless-controller vap
edit "Guest_Wi-Fi"
set ssid "Guest_Wireless"
set security captive-portal
set portal-type auth+disclaimer
set selected-usergroups "Guest_Wi-Fi"
set security-exempt-list "Guest_Wi-Fi-exempt-list"
set schedule "always"
next
end

[Debbie_FTNT]

Hey Anand,

For your point 2:

- FortiGate gets a new connection it can't identify straight away because the SAML cookie is not there (restart the PC, for example) or doesn't match up to existing authentication (change in IP address, user login was removed on FortiGate, or similar)

- FortiGate directs to Office365 (as that handles the auth)

-> Office365 would STILL have an authentication session for the user unless that expired, and shorten the whole process (provide a new cookie, inform FortiGate that user is authenticated) without an active user login required

-> the user would (maybe) see the browser go to Office365 and then immediately back to FortiGate and then internet

-> The active user login would only be required if Office365 doesn't have any cached information for that client

-> I have no idea what settings you would have available on Office365 to force an active re-authentication

For your point 1:
- changes in group membership might not clear the existing authentication session in Office365

- user would still have the authentication cookie from before the change in group membership, which FortiGate would still accept

-> user doesn't know their group membership changed and will simply keep the cookie until restart/cookie expires

-> you would have to force a reauthentication by clearing the login on FortiGate and Office365 both to get the updated group information

For your point 3:

- cookie validity times, and authentication timeouts, are primarily up to Office365.

- On FortiGate you would have a default 5 minute idle-timeout I believe (if the user wasn't active for five minutes, the login gets removed).

-> however, re-authentication might happen entirely in the background without the user noticing much, see above

I hope that clears up how SAML SP (FortiGate) and IdP (Office365) interact with each other