Forum Discussion

tmherron_91852's avatar
tmherron_91852
Icon for Nimbostratus rankNimbostratus
Nov 01, 2012

SSL session and cookies

 

Our client is looking for a logical client log out functionality. In effect, the client should always be required to provide his/her credentials (CAC certificate) after logging out. The cookies cache by the client are preventing new sessions. Since we cannot delete the clients cookies in their browsers, could you provide information or code to terminate a client SSL connection/session?

 

6 Replies

  • Are you looking for idle time logout. If yes, login to the LTM as Admin and scroll to System -> Preferences -> Idle time before automatic logout.

     

     

    update the value in seconds to reflect for the system.

     

     

    -Santosh
  • Since we cannot delete the clients cookies in their browsersis setting cookie expire in irule helpful?

     

     

    HTTP::header insert "Set-Cookie" "name=; path=/; Expires=0"
  • we cannot delete the clients cookies in their browsers

     

    right, but we can delete the cookies that they send before they make it to the web server, which is the same thing :)
  • Our client requires a "logical logout" which to them means that the user must be forced to produce and select his credentials (Certificate). Session cookies do not time out and deleting the cookie in the http request does not force the client user to produce and select is certificate and ending the SSL session does not delete the cookie from the users browser. I am wondering if I could use irules inject javascript to call document.execCommand("ClearAuthenticationCache");

     

  • just wondering whether SSL::session invalidate is helpful.

     

     

    SSL::session

     

    https://devcentral.f5.com/wiki/iRules.SSL__session.ashx

     

     

    I am wondering if I could use irules inject javascript to call document.execCommand("ClearAuthenticationCache");you can use stream project to inject javascript.

     

     

    iRule to Inject Javascript

     

    https://devcentral.f5.com/Community/GroupDetails/tabid/1082223/aft/2154823/asg/50/Default.aspx
  • 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.