If we get the memory problem fixed (maybe there is a fix in FW 5.2.3, I did not see anything about this in the release notes) we will dig deeper in the web portal. Maybe it detects the login and password fields in the form and just tries it. There is not much documentation how this feature works. I just don't know why the fortigate support this. On the authentication side, we only saw authentication working on a custom tomcat application with a form based authentication (via HTTP post). When I use the sites through the Web portal, the fortigate gets a memory problem within seconds, switches in conserve mode, killing around 1000 open sessions to make more ram. We reconfigured the IIS Instances because of the heartbleed attack with 'IISCrypto', disabling SSL v3 and stuff. On the web portal we found a bigger problem. We still have weird problems with identity based policies on the ssl vpn, sometimes the forticlient does not register itself with the forticlient so the forward traffic is denied, other times the client is shown as another client which had the ssl vpn ip before (all on FW 5.2.2 with Client 5.2.3). You have to do it through SSH.Ītlassian Confluence and JIRA are using the same form input fields. If not you have to add the fields by yourself.Īt least in v5.2.3 there is a bug where you couldn't add more than one input field.

If your server uses 'login' and 'password' as html input name fields for the login form it works with SSO auto. If you use any URL that cause a HTTP redirect the login would not work! You have to use the login URL in the bookmarks. We found time to implement some bookmarks with SSO:

Jira rss feed outlook