SAML Cookie Persistence after browser/system restart and across service providers
I am fairly new to the F5 world and in the beginning of setting up our LTM's as SAML IdP's for a variety of services. Our first use-case is Jive, which we have working and all the attributes are pulling across just fine, authentication is fine, everything is functional as is. I'm having a hard time translating what we want the user experience to be into the next phase of the configuration. Our hope was that we could authenticate a user to the LTM, they would be provided a cookie that was set to expire in 24 hours, that cookie would provide SSO access to other services that we'll be adding, and once the 24 hours is up the user would be asked to authenticate again regardless of which service they are logging in to. I've set the Maximum Session Timeout to 86400 seconds (24 hours) and set the cookie to persistent, but when I log in with a test account I don't see a new cookie created on the user system and closing the browser loses the session. In addition, I don't have another sandbox service provider to test with currently to ensure that the cookie we are hoping will be creating would be valid for that other service as well. Am I wrong in thinking that the F5 can provide a persistent cookie that survives beyond browser or systems restarts? Can the F5 only provide SSO for that time period and across SAML partners as long as that browser session is open? I presume I'm asking some pretty elementary stuff so forgive my lack of current knowledge. Any pointers on where I can read up on that or help managing my expectations would be appreciated.
iRule needed to clear specific cookies from particular domain
Recently we moved our peoplesoft system to a subdomain of our DNS space. So instead of all our VIPs being for example, prod.abc.com they are now prod.ps.abc.com Peoplesoft uses a cookie for single-signon and some other features. The primary cookie is PS_TOKEN, but there are others as well. This move, for the most part, was seamless. However we have a particular case generally involving Safari on mac where the browser can submit the old domain token (cookie), which will sometimes cause the browser to "loop" the guest authentication page hundreds, or thousands of times a minute. We have demonstrated that clearing the old domain cookies will solve the issue. We have demonstrated this using a static webpage with some javascript that is hosted on an address on the old domain (abc.com). If a browser with the "old" cookie visits our page in between, then it is cleared and works. This is a rather manual solution, and redirecting everyone there before logging in would seem to be one solution - but that will not work as we have some deep links that would be broken in that case. What I desire (and have tried to create a few ways) is an iRule to: Check for the existence of the cookie PS_TOKEN (and possibly others) Check that the cookie domain of that cookie(s) is .abc.com If so, delete it (or if necessary set it's expiration to -1, which is what our js had to do) Then pass the request on through to wherever it was headed to start with. Ideally using the pool already defined for the particular virtual server. I haven't been able to get even the basics to seem to work. So I dropped back to seeing if the cookie is even being read by the F5, so here is where I sit now: when HTTP_REQUEST { if {[HTTP::cookie domain "PS_TOKEN"] contains ".abc.com"} { HTTP::respond 200 content {found abccom cookie} } else {HTTP::respond 200 content {did not find cookie} } } This never finds the cookie (at least it doesn't tell me it did). Any help and direction is most appreciated.
Modified domain cookie TSPD_101
Based on the article we know that the cookie TSPD_101 can be set by ASM even there's no Proactive Bot Defence or DoS-Profile aktive. We have set the type of the cookie with name: * to Enfored, which means that a cookie set (at server side) may not be changed by the client. Interesting is that ASM complains about TSPD_101 has been modified. Do we have to define the TSPD_101 cookie explicit with type Allowed?Persistence Profile Issues
I am having an interesting issue with a persistence profile. It works wonderful in QA but is not working in production. I've created a persistence profile with the following attributes: Parent Profile Universal Mirror Persistence Enabled iRule Enabled and pointed Timeout Enabled and set to 28800 seconds The iRule: when HTTP_RESPONSE { if { [HTTP::cookie exists "ASP.NET_SessionId"] } { persist add uie [HTTP::cookie "ASP.NET_SessionId"] pool po-server-https } } when HTTP_REQUEST { if { [HTTP::cookie exists "ASP.NET_SessionId"] } { persist uie [HTTP::cookie "ASP.NET_SessionId"] pool po-server-https } } In the virtual server instance I then set Default Persistence Profile to this new created profile. This all works wonderfully in QA and the client is persisted to one server based on their cookie value for ASP.NET. The pool names are correct, the cookie exists in both environments etc. but in production, the persistence is not taking place and the client is jumping between servers in the pool. Does anyone have ideas on this one or a path forward to troubleshoot this via clean logging that doesn't inundate the server?
irule to remove all cookies
Hello, we are testing an irule to remove all cookie from the client browser after an idle time, the cookie for TCP isn't what we are looking for rather than the actual cookie sent to the server. any suggestion on how to achieve this, if I inserted a cookie manually I want the irule to delete it after I refresh the page. we are testing this on BIG-IP LTM ?irule example : when HTTP_REQUEST { } when HTTP_RESPONSE { set cookieNames [HTTP::cookie names] #array of cookies foreach aCookie $cookieNames { #adding the cookies to the array in a varaible aCookie HTTP::cookie remove $aCookie #removing the virable } }
