Forum Discussion
KellyS_50017
Nimbostratus
NimbostratusProfile 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?
KellyS_50017I worked on this awhile longer this weekend, as I also noticed that persistence wasn't being kept after the token was redeemed. So, I have two irules (should they be combined?)
Here's the first:
when HTTP_REQUEST {
if { [string tolower [HTTP::uri]] starts_with "/abcd" } {
persist cookie insert SSO
pool SSO_Pool
}
}
And the second to keep them going to the SSO pool after they login:
when HTTP_REQUEST {
if { [HTTP::cookie exists "SSO"] } {
pool SSO_Pool
}
}
Any issues with this? My limited testing seems great so far.
hooleylistCirrostratus
You could combine the two rules into one. Using HTTP::path will be more efficient than using HTTP::uri (which is the path and the query string).when HTTP_REQUEST { if { [HTTP::cookie exists "SSO"] } { pool SSO_Pool } elseif {[string tolower [HTTP::path]] starts_with "/abcd" } { persist cookie insert SSO pool SSO_Pool } }
That said, I'm not sure I understand your scenario completely. It sounds like you've had to use a single pool member at a time in order to get this to work. Could you instead have all four members set to the same priority and persist based on the four letter string in the URI along with UIE persistence? If you think this is possible, could you post a few anonymized examples of the requested URIs for two or three clients as they access the application?
Aaron- KellyS_50017Thanks for the reply and the re-work of my iRules - I tried it in our test env and it works great. I plan on putting this into Prod later today.
I'll explain a hair more - 99% of our traffic goes against a regular pool. 1% of our traffic comes in through this single sign on applet, and the node that issues the token has to be the node that redeems the token. The client using this the most doesn't have the same machine ask for & redeem the tokens - one server asks for the token, then passes it to another workstation to redeem it. So I needed a way to funnel all this SSO traffic to a single node, yet try to have some sort of HA available if the node goes down.
I duplicated the pool the website runs on (adding _SSO to the end of the name) and turned on priority activation, and gave each node a number.
Is there a better way to accomplish this? - hooleylistBased on your description, I think the configuration you've built is fine.
Aaron