Forum Discussion
MR_RJ
Cirrus
CirrusNeed a iRule to set persistence based on http content
Hi,
We are using RSA-SecurID and their solution how to configure a web farm that is load balanced. The short story, the agents on the servers act as one agent and if you are authenticated to one server, then you are authenticated to all of them.
This works really well together with the F5 LTM. ...except for one thing. If the password is entered wrong several times there will be a form of a challenge prompted to the user. When the user is submitting this the request/response might go to another server then it originated from.
I'm very new to iRule, we havent had any major challenges so I've only created a few simple ones.
But anyway... the solution I was thinking of was a iRule that is doing something like this:
when http_respons {
if { http::uri contains "/securid/agent.dll" && http::payload contains "SecurID Next Tokencode Request" } {
}
I've been playing around a bit with the idea and trying to create a iRule for it but I'm not even sure that this is the right approach. I've seen some similar solutions but they seems to be a bit to advanced for what I'm trying to do.
Worst case scenario is enabling persistence on all sessions but then we will have a long drain time etc, now I can (if needed) just force a node offline and no one will notice... that's worth a lot.
Any ideas of other solutions or how to write the iRule?
Thanks in advance!
Robert
- The_Bhattman
Nimbostratus
Hi Robert,
Have you tried using cookie based persistence?
Bhattman 
MR_RJHi,
The thing is, enabling persistence on the whole site will lead to some down sides as draining etc. so I'm looking into this solution, trying to just make a persistence on the connections/sessions that will be prompted for a next token mode. So when the uri is /blah/secureid.dll and the webserver returns a page that includes "SecurID Next Tokencode Request", that's the only time I would like to enable persistence so the user can enter/submit the next token thingy.
//Robert- The_BhattmanHi Robert,
Cookie persistence doesn't place the burden of resources on the F5 or the client, if that is what you are concerned about. However, being specific based on the URI you can certain use persist uie
You can find many different examples that you can draw on.
Click Here
I hope this helps
Bhattman - MR_RJHi,
I've been looking into a few of those examples and most of them add a persist on either the uri or the content.
I would like to match on both things, if the uri is /blah/securid.dll ...then check content from the web server for "next token..." if these two are true then add the session to the persistent table. This solution should lead to only a few persistent connections which makes the maintenance a lot easier since putting the nodes in disabled would drain the sessions in just a few minutes like it does today (except for the ~3 users that is persistent atm).
//Robert - The_BhattmanHi Robert,
To match the content side you need to use HTTP::collect and HTTP::payload along with the persist UIE. You can find the wiki resource for HTTP::Collect and HTTP::payload here
http://devcentral.f5.com/wiki/default.aspx/iRules/HTTP__collect.html
http://devcentral.f5.com/wiki/default.aspx/iRules/HTTP__payload.html
I hope this helps
Bhattman 
hoolioCirrostratus
I don't think the overhead of collecting payloads to limit when you use persistence is worth it. Collecting payloads is going to eat up a fair amount of memory and add latency.
As Bhattman suggested, using cookie insert persistence for all requests is going to be a lot more efficient from the LTM perspective.
Aaron- Even though you can achieve what you're looking for relatively efficiently with the STREAM profile and other built in commands, I have to agree with Bhattman and hoolio here. The overhead for enabling site-wide cookie persistence is minimal on the F5 device. If that's your concern, I really wouldn't worry about it unless your system is already nearly maxed out, at which point there are other concerns to deal with anyway.
Colin
