NimbostratusHi, Can anyone help with how to setup persistence for a request as below:
We are going to be setting a "jvmRoute" variable in tomcat, and need to configure the F5 load balancer to concatenate it ("jvmRoute") with JSESSIONID to generate final SESSIONID.
Employeedo you mean concatenating jvmroute and jsessionid to be a persistence key? are you using universal persistence?
if yes, you can just put them together e.g. [HTTP::cookie "JSESSIONID"][HTTP::cookie "jvmRoute"].
sol7392: Overview of universal persistence
https://support.f5.com/kb/en-us/solutions/public/7000/300/sol7392.html
NimbostratusEmployee
Noctilucentdo you mean concatenating jvmroute and jsessionid to be a persistence key? are you using universal persistence?
if yes, you can just put them together e.g. [HTTP::cookie "JSESSIONID"][HTTP::cookie "jvmRoute"].
sol7392: Overview of universal persistence
https://support.f5.com/kb/en-us/solutions/public/7000/300/sol7392.html
NimbostratusNoctilucent
NimbostratusSince jvmRoute is already appended to the JSESSIONID by Tomcat you can just consider it as part of the JSESSIONID. The irule in the linked page should work out of the box.
Note that setting the jvmRoute in Tomcat server.xml has no added value from a universal persistence perspective. It only appends a string to the JSESSIONID but does not make it more unique.
For one client I created an irule that only use the jvmRoute part of the JSESSIONID to select the backend. It probably as slightly more processing overhead but limits the number of entries in the session table. However, unless you have extreme numbers of current user sessions I would recommend using the example iRule from the page you referred to.
NimbostratusHi All,
We have similar requirement i.e. to persist at BIG-IP level in this pattern "JSESSIONID.jvmRoute". I would like to know if this iRule below would help us in achieving that goal.
when HTTP_RESPONSE {
if { [HTTP::cookie exists "JSESSIONID"] } {
persist add uie [HTTP::cookie "JSESSIONID"][HTTP::cookie "jvmRoute"]
}
}
when HTTP_REQUEST {
if { [HTTP::cookie exists "JSESSIONID"] } {
persist uie [HTTP::cookie "JSESSIONID"][HTTP::cookie "jvmRoute"]
}
}
Regards, Ram
NimbostratusHi Ram,
As I indicated Tomcat appends the jvmRoute to the JSESSIONID. Tomcat does not set a separate jvmRoute cookie so [HTTP::cookie "jvmRoute"] will always return an empty string.
Bottom line is that the standard JSESSIONID irule should work fine.
Rgds,
W.
NimbostratusThanks for quick response, Winston!
I'll implement the above iRule without [HTTP::cookie "jvmRoute"] and post the results. Out tomcat instance already has jvmRoute configured in server.xml file.
Regards, Ram
NimbostratusHi All,
Along with above requirement, we would like to encrypt the Cookie content. So there is already a Profile under Persistence that we created to use HTTP Insert Cookie method and encrypt the Cookie content using a passphrase. I would like to know if it is okay to have a profile separately to encrypt along with this iRule or do we need to modify the iRule to have them together. Like, have JSESSIONID and encryption of Cookie content in a single iRule.
when HTTP_RESPONSE {
if { [HTTP::cookie exists "JSESSIONID"] } {
persist add uie [HTTP::cookie "JSESSIONID"]
}
}
when HTTP_REQUEST {
if { [HTTP::cookie exists "JSESSIONID"] } {
persist uie [HTTP::cookie "JSESSIONID"]
}
}
Regards, Ram
NimbostratusI fail to see what the benefit of encrypting a JSESSIONID would be. By definition it is a random string. Encrypting it does not seem to have any value.
You should make sure that it is marked as Secure and HttpOnly, but most application servers will do that by default.
NimbostratusThis is for encrypting Cookie content to improve security. It is a PCI requirement.
NimbostratusBut I don't think encrypting the JSESSIONID cookie improves security at all. It is just a random value that is a pointer to a session object in an application server (e.g. Tomcat). Encrypting it doesn't do anything but turning it into another random value. If a hacker gets hold of the encrypted JSESSIONID (s)he can still just pass it along with a request and it will get descrypted on the fly by LTM.
You could even argue that encryption even weakens your security as your are (arguably low) using CPU power for unnecessary stuff.
NimbostratusHi Winston,
I was referring to this KB to encode the pool member information.
https://support.f5.com/csp/article/K23254150
IPv4
BIGipServer=..0000
IPv6
BIGipServer=.
During security audit we found out that our member pool information were in 'plain text' so we had to encrypt the Cookie.
Regards, Ram
NimbostratusBut in your post you pasted an irule that has nothing to do with LTM cookie persistency. Instead it is about jsessionid persistency which happens to use a cookie as well.
If you use LTM's own cookie persistency it makes sense to use cookie encryption since it contains sensitive ip information. If you use jsessionid persistency encryption does not make sense (to me).