I've created an iRule that chooses a WEBSSO profile depending on different parameters obtained through various methods (user/pass, host header, etc.). I now seem to have run into an issue where the F5 tries to do the WEBSSO against a server, but when that server rejects it (because the user isn't allowed there for example), the rest of the WEBSSO profiles no longer work.
I can see an entry in the websso debug logs:
Jun 4 11:10:43 slot1/viprion debug websso.0: 014d0001:7: sso_disable: 1, _needAuth: 0
Once I've seen this message, all SSO stops working, even for other hosts on other connections within that same session.
Here's the usecase:
- we navigate to URL A
- we're presented with the APM logon screen so we enter our credentials and we are in
- sso is being done against the backend server behind URL A, the iRule chose the SSO profile and the backend server based on our URL A
- everything works so far
- we navigate to URL B, the same thing happens, we get in, the websso does its job
- but then we navigate to URL C, the websso fails to login because the backend for URL C isn't allowing us access
- the log line is shown in the APM log (with websso logging set to debug)
- we cancel the authentication popup, because if websso didn't help us get in, we're not meant to go further; so we press escape, the server returns an "401.x unauthorized page"
- we then navigate to URL A again, and suddenly we're presented with a popup to log in to server A, eventhough it worked just a minute ago
- killing the APM session, restarting it and then going to URL A again, fixes it.
- once we hit URL C though, the websso dies.
So I'm thinking that the websso module tries X times to log you on, if it doesn't work, it gives up and you're presented with the server's response as-is (which is a 401.x unauthorized, which means we get a popup in the browser for logging on).
The thing is, if it has given up on this server, why is it no longer doing anything for the other servers?
Ok, small update, I found the thing that fixes it:
There is a session variable that is being created when the SSO has failed. This variable is sso.state=1, it is set below whatever you've put in the username source field of the SSO profile. So for me this was "session.sso.custom.username", which makes it "session.sso.custom.username.sso.state=1".
I used an iRule provided by mrrobbins in some post to detect when this variable is set to 1 and to change it back to 0 whenever it occurs.
I'm guessing this has some implications towards security because the websso fail-X-times-and-die thingy is circumvented; I'm supposing the fail-X-times-and-die was implemented for a reason.
I've solved this problem by not configuring the "success" section of the WEBSSO profiles.