For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Lee_Keener_5402's avatar
Lee_Keener_5402
Icon for Nimbostratus rankNimbostratus
Aug 27, 2015

iRule for HTTP Status and specific header not working

Greetings,

 

I have a web application developer asking me to be able to clear the WWW-Authenticate header when the HTTP status is 401. I wrote the rule below thinking it would work but it seems to clear out ALL WWW-Authenticate headers. I am no TCL expert so I'm guessing I have some kind of mistake in the logic. Any help would be greatly appreciated.

 

when HTTP_RESPONSE { if { [HTTP::header exists "WWW-Authenticate"] and [HTTP::status] == 401 } { [HTTP::header replace "WWW-Authenticate" ""] } }

 

We've done TCP Dumps and seen it clear the header when HTTP Status is 200, This causes interference with a SPNEGO negotiation. We only want it cleared during 401 status as to prevent a single page web app from losing it's context during a session timeout.

 

4 Replies

  • Forgot to add that I'm quite confused about when to use the brackets and curly braces, operators etc... so it;s quite possible I've misused those. Thanks for your help.
  • A few things:

    1. Can you elaborate on wy you'd expect to see a WWW-Authenticate header in a 200 response? Even for a SPNEGO authentication it should only be valid in a 401.

    2. If you do:

      HTTP::header replace WWW-Authenticate ""
      

      that just inserts the header with an empty value.

  • Hi Kevin, Thank you for your answer. I'll try as best I can to answer your questions.

     

    We are wanting to clear the WWW-Authenticate header so that the single-page-applications will not lose context. My developer is telling me that clearing or setting "" for this header allows them to popup a dialog to reauthenticate within their application. If the header has the value set by the server the browser will intercept and attempt to reauthenticate the session, This causes the SPA to lose context and if the user was in something like a Map, they've lost everything and go back to app initial state. All of this works as expected in regard to our apps however when we have this particular iRule applied, the internal users on Domain computers cannot connect as the SSO is broken and the initial SPNEGO negotiation response is removed..

     

    We ran TCP Dumps against a SPNEGO Login and see 200 response with WWW-Authenticate header with value of Negotiate and a whole bunch of Key stuff. We do not want to modify that header, only when the response is 401, which I beleive would only come from a session that can;t negotiate SPNEGO. I am not an epxert on the SSO stuff so please forgive me if I have some of this wrong. Going to try and attach a screenshot of one of the pcaps.

     

    To summarize, the iRule I have above works fine for what we want in regard to allowing an expired session to be re-authenticated within the web application, without the user losing their context. However it breaks by clearing the header when the status is 200. Does my rule have the if statement constructed proerly to only work when the status is 401 and the WWW-authenticate headers exists? It does not seem to work that way and is clearing out the needed SPENGO keys coming back from the server.

     

  • I don't think there's anything technically wrong with what you have, but try this minor modification:

    when HTTP_RESPONSE { 
        if { ( [HTTP::status] eq "401" ) and ( [HTTP::header exists WWW-AUTHENTICATE] ) } {         
            HTTP::header replace WWW-Authenticate ""             
        }         
    }