Forum Discussion
Lucas_Thompson_
Nov 02, 2015Historic F5 Account
Basically, in the context of a user connection, zero or one SSO can be "selected". If you don't apply any to assigned Portal Access resource items (basically Allow ACLs that ALSO switch the SSO), then the default SSO for the Access Profile is selected.
To complicate this a little more, there is also "multidomain SSO" that switches the selected SSO depending on the host header received from the client's browser.
You can also switch the SSO manually if you want by using WEBSSO::select during the ACCESS_ACL_ALLOWED event.
For Client-Initiated SSO, a few conditions must be met in order for it to insert the JS into the login page and do the auto-POST behavior:
1. The SSO must not be disabled from a previous unsuccessful logon attempt for the session (you would see something like "sso disabled for this session").
2. The SSO must be selected to the correct one (this is visible in the logs).
3. The SSO must detect the correct URI in the web page (this is visible in the logs).
4. The SSO must detect the form (also in the logs)
5. There must be no JS errors that stop the browser from executing the injected JS (look for errors in the Dev Tools console in Chrome or FF).