SSL session and cookies

You really want to destroy the cookies on the client side, so you'll need some way to know when a logout event is happening. There are probably a few ways to skin this cat, depending on the application.

1. if you know the names of the cookies (and attributes) up front, and you can detect some kind of logout event (ie. user clicks a logout button/link) you can systematically delete the cookies in the logout response.

when HTTP_REQUEST {
   if { [HTTP::uri] starts_with "/logout" } {
      set logout 1
   }
}
when HTTP_RESPONSE {
   if { [info exists logout] } {
      unset logout
      HTTP::header insert "Set-Cookie" "cookie1=1; path=/; expires=Tuesday, 29-Mar-2005 00:15:00 GMT"
      HTTP::header insert "Set-Cookie" "cookie2=1; domain=mydomain.com; expires=Tuesday, 29-Mar-2005 00:15:00 GMT"
      ...
   }
}

One important thing to remember about cookies is that uniqueness is defined by the set of attributes, not just the name. For example:

cookie1=1

cookie1=1; path=/

cookie1=1; domain=mydomain.com

are really three different cookies. If you want to delete them in the browser you need to know how they were set. You're probably not going to have to delete every cookie to delete the application session either, just a select few.

2. If you don't know about the cookies beforehand, you could conceivably capture the HTTP_RESPONSE Set-Cookie statements and store the names/attributes in a session table for the user (a quasi-cookie jar) and then expire them using the session table upon the logout event. You don't need to store the values, just the name, path, and domain attributes.

3. As Nitass stated, you can also easily insert some JavaScript in the response to call your "CleatAuthenticationCache" function. So if the logout event is triggered in the HTTP request, disable the STREAM profile and set a flag. In the HTTP response event, if the flag exists, replace the end body tag with your JavaScript and a new end body tag. This'll cause the JavaScript to execute post-page-render. If you need it to fire earlier, then replace the end head tag instead.

You'll also want to execute the SSL::session invalidate command which causes the server side SSL cache to be destroyed. This and the client side cookie deletion should completely destroy the session, however not all browsers will re-prompt for client certificate by default - opting to "remember" your last selection. There's really nothing you can do on the BIG-IP-side to change that behavior. Just know that they'll be generating a new session, albeit with the same certificate.