Forum Discussion

Jure_48098's avatar
Jure_48098
Icon for Nimbostratus rankNimbostratus
Feb 15, 2008

SSL login redirect

I have a site that I'm tryng to migrate to LTM, that is running HTTP and HTTPS. The login POST always goes to the SSL server. Server then does the auhorisation and returns a HTTP 302 redirect with the Referer URL as the new Locaton (and some new cookie)..

 

In it's current version, there are some proxies in front of the application server (thar really does the content) and SSL is terminated there.

 

 

Now I terminate SSL on the LTM and have only the http proxy in between. The trouble is, that whenever a user logs in, he gets a 302 redirect to the HTTP site, because the server always returns a HTTP redirect (uses just the path part of Referer) and before the SSL proxy took care it remaped that to SSL if needed.

 

 

What I'd like to know, is there a way to keep state in an iRule of the Referrer location when the user request arrived and the server issues a response, so I could redirect the ones that have HTTPS referer to HTTPS and leave the HTTP ones as they are..

 

 

One other idea that comes to my mind is, to insert a ?ssl or something in the Referer header on the way in and delete it + redirect to SSL on the way out.

 

 

What is the best way to handle such an issue?

 

 

Thanks

 

Jure
application delivery
dev
devops
iRules

7 Replies

Sort By
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Feb 15, 2008
    Do you know what the logic was that the SSL proxy used? That should be something you could implement in an iRule without making any changes. Are the login requesta always made to the same URI (like /login.php, for example)?

     

     

    Aaron
  • Jure_48098's avatar
    Jure_48098
    Icon for Nimbostratus rankNimbostratus
    Feb 15, 2008
    The login goes always to the same URI.

     

     

    The login is a POST and if the referrer is a https, the response from the server is a real server IP + some nonstandard port, which gets translated by the apache proxy. If the referer was a http://, then the server returns a valid URL, so the proxy doesn't do any translations..

     

     

    HTTPS -> 302 Location: http://real.server.ip:port/URI (gets translated to https://FQDN/URI)

     

    HTTP -> 302 Location: http://FQDN/URI
  • Nicolas_Menant's avatar
    Nicolas_Menant
    Icon for Employee rankEmployee
    Feb 18, 2008
    Hi,

     

     

    I'll consider the host is always the same and you know the URI that should be returned (i'll consider again it is a static value)

     

     

    it should looks like something like this:

     

     

    when HTTP_RESPONSE {

     

    if { [HTTP::status] starts_with "3" } {

     

    if { {[clientside {TCP::local_port}] == 443} } {

     

    HTTP::header replace Location "https:///

     

    }

     

    }

     

    }
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Feb 18, 2008
    One suggestions on that. If the redirect location changes (ie, the URI is dynamically set) and you need to preserve this, you can replace the only host portion of the redirect with the FQDN using a rule like this:

    
when HTTP_RESPONSE {
   if {[HTTP::is_redirect]}{
      set domain_name "host.example.com"
      log local0. "\[IP::remote_addr\]:\[TCP::remote_port\]: [IP::remote_addr]:[TCP::remote_port]"
      set string_map [string map "[IP::remote_addr]:[TCP::remote_port] $domain_name" [HTTP::header value Location]]
      log local0. "string map: $string_map"
      HTTP::header replace Location [string map "[IP::remote_addr]:[TCP::remote_port] $domain_name" [HTTP::header value Location]]  
   }
}

    Or without logging/intermediate variables:

    
when HTTP_RESPONSE {
   if {[HTTP::is_redirect]}{
      HTTP::header replace Location [string map "[IP::remote_addr]:[TCP::remote_port] host.example.com" [HTTP::header value Location]]  
   }
}

    Aaron
  • Jure_48098's avatar
    Jure_48098
    Icon for Nimbostratus rankNimbostratus
    Feb 25, 2008
    Thank you for this. Unfortunately I can't just do an iRule Location rewrite if the reply is a 3XX redirect, because the response from the proxies to the LTM is the same whether the original request came from the SSL site or the HTTP one. I need to track and match:

     

     

    1. if the client request to POST loginURL has Referer: https://someURI

     

    2. do the response 3XX rewrite Location to https://someURI (it's always http://someURI in the response)

     

    3. otherwise it works as planned (do nothing as it is http://..)

     

     

    So I need to match the client request Referer and the server response and do the Location rewrite in case the original request had HTTPS Referer header.

     

     

    The problem is that in the old setup, there were separate HTTP and SSL proxies that did this rewrites correctly, now there is only the HTTP one and I have to handle this logic on the LTM..

     

     

    One way I see is to insert some SSL identifier into the original reguest Referer URL, like if it is an HTTPs one, add ?SSL to the URI in the Referer so I'd see it when the response (redirect to this Location) comes back from the server.
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Feb 25, 2008
    If you only want to rewrite some responses, based on request criteria, you could add logic to the HTTP_REQUEST event:

    
when HTTP_REQUEST {
   if {[HTTP::method] eq "POST" and [HTTP::header value Referer] starts_with "https://"}{
      set rewrite_redirect 1
   } else {
      set rewrite_redirect 1
   }
}
when HTTP_RESPONSE {
   if {[HTTP::is_redirect]}{
      HTTP::header replace Location [string map "[IP::remote_addr]:[TCP::remote_port] host.example.com" [HTTP::header value Location]]  
   }
}

    Aaron
  • Jure_48098's avatar
    Jure_48098
    Icon for Nimbostratus rankNimbostratus
    Feb 28, 2008
    Thanks a lot. I ended up with an iRule that checks if the Referer starts with https + request is https and response is a redirect, then rewrite the Location to https as it turned out there were multiple 3XX pages..

     

    All fixed..