Forum Discussion

David_R_Joslin's avatar
David_R_Joslin
Icon for Nimbostratus rankNimbostratus
Feb 11, 2014

Insert auth pool request transparently between every call to an application pool.

I have something working but I am not sure if there is a more efficient way. One requirement is that the criteria for determining if the request came from auth is not spoofable. That pretty much eliminated headers. I tried playing with sharedvar but could not make it work with the auth proxy. Given that this will execute with every call to our app, I want to be as efficient as possible.

Thanks!

 iRule to insert a trip through the auth servers
 before every request to the application. 
 Assumes that the auth servers forward every 
 successfully authorized request to the original url.

when HTTP_REQUEST {
   capture the current pool
  set AppPool [LB::server pool]

   define the Auth server pool
  set AuthPool "TEST_AUTH_80"

  Set the current pool to the Auth Pool.
  pool $AuthPool

   capture the client IP in the format presented by the 
   [members -list [LB::server pool] command.
  set clientIPPort "[IP::client_addr] 80"

   If the client IP is in the Auth pool list, the request is being
   forwarded from the Auth servers and should go to the Application pool.
   Else send to the Auth Servers.
  if {  [members -list [LB::server pool] ] contains $clientIPPort } {
    log local0. "client: $clientIPPort IN $AuthPool sending to $AuthPool"
    pool $AppPool

  } else {
    log local0. "client: $clientIPPort NOT IN $AuthPool sending to $AuthPool"
    pool $AuthPool
  }
}
application delivery
devops
iRules

3 Replies

Sort By
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Feb 12, 2014

    A few questions:

     

    1. Can you elaborate on how the traffic flows through this iRule?

       

    2. Have you verified that traffic actually does flow through the auth pool?

       

    3. How does traffic flow through the auth server? Does it pass through or return a response?

       

  • David_R_Joslin's avatar
    David_R_Joslin
    Icon for Nimbostratus rankNimbostratus
    Feb 12, 2014

    Sure. Thanks.

     

    re 1 The auth servers are nginx proxy that inserts headers that are consumed by the application. Once the headers are inserted it forwards to the original url, this hitting the snat from the inside interface. In it's current form, the irule sees the client ip as that of the auth server and then passes the request to the application server.

     

    re 2 Yes.

     

    re 3 I think I answer that in 1. Let me add that the original design by the devs had the auth servers load balancing the app servers themselves. Basically ruby/nginx devs doing their thing. The problem was that every auth proxy had to be application aware. We started working on this solution so that we could have a large pool of identical auth servers serving many different applications and that auth servers are application agnostic.

     

    I think what I am really looking for or trying to confirm is that the request has been through the auth pool before being routed to the application. Headers can be spoofed, so this clientIP lookup seemed OK. I am not sure how expensive it is from a performance perspective though.

     

    Thank you for you looking. Much appreciated.

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Feb 12, 2014

    Interesting. So then correct me if I'm wrong, but the client traffic enters the VIP and iRule and is initially sent to the auth pool. The auth pool proxy server SNATs the request, adds some headers, and sends it back to the front of the VIP, which then sends the traffic to the app server (by virtue of the new source address). In any case, I see no harm nor performance impact doing it this way. I'd also add though that you could do an HTTP::header replace inside the iRule right before sending to the auth pool, which would overwrite any attempt to spoof the HTTP header.

    ...
if {  [members -list [LB::server pool] ] contains $clientIPPort } {
    log local0. "client: $clientIPPort IN $AuthPool sending to $AuthPool"
    pool $AppPool
} else {
    log local0. "client: $clientIPPort NOT IN $AuthPool sending to $AuthPool"
    HTTP::header replace AUTHSEND "something"
    pool $AuthPool
}
...