KellyS_50017
Dec 20, 2008Nimbostratus
Profile vs iRule, case sensitivity, persistence
Super-simple question, as I'm pretty new to the F5's.
We have a single sign on piece to our web site that requires the node that issued the SSO token to be the node that redeems the token. Normally this isn't a problem but one of our clients uses an intranet server to initiate the token request, then passes the token to the workstation requesting it, so it's two different systems that need to go to the same node. Luckfully, the SSO requests & redemptions all go to a single 4-letter folder, let's call it /ABCD/. What I've read so far & gleaned from class is you do Profiles first, then iRules. Less iRules the better. No Regex unless you absolutely have to.
SO here's what I did:
1) Duplicated our main pool calling it the _SSO version of it, using priority activation (1, 2, 3, 4) and setting it to less than 1 member. That will keep all requests to one node unless that node becomes unavailable, then we switch to 2, 3, 4, etc. (tell me if I have this wrong)
2) Created a profile to catch the uri of /abcd/ and forward it to the _SSO pool.
Thought I was so smart until I noticed it's case sensitive. It only works if the request is www.company.com/abcd/whatever.asmx - /ABCD/ isn't caught (because it doesn't match the /abcd/ I setup in the profile)
So, I changed to an iRule, like the following:
when HTTP_REQUEST {
if { [string tolower [HTTP::uri]] eq "/abcd/*" } {
pool Main_SSO
}
}
Is this the right direction I should go? Does anyone have a better solution? I thought about adding 16 entries to the profile (abcd, Abcd, ABcd, etc) but that seemed silly.
What can I do to keep persistence to that _SSO pool after the workstations redeem the sso token?