How to use haproxy for oathkeeper API integration

[meinrecht]

There is this guide how to set up traefik to access the oathkeeper API here:
https://www.ory.sh/docs/oathkeeper/guides/traefik-proxy-integration

Is this possible with haproxy too? Any examples?

[vinckr]

Should be possible, if you have a good example please share it here 👍

[meinrecht]

Basically this works via a lua script for haproxy.

A basic script is described in the section "Verify a request with another service" of the documentation.

This script can be modified like this, assuming an oathkeeper-instance listens on the default API port:

core.register_action("verify_request", { "http-req" }, function(txn)
   local s = core.tcp()
   s:connect("127.0.0.1:4456")
   s:send("GET /decisions" .. txn.sf:path() .. " HTTP/1.1\r\n" .. txn.f:req_hdrs())
   local msg = s:receive("*l")
   -- connection failure
   if msg == nil then
      -- This leave txn.request_verified unset for potentially diffrent handling
      return
   end
 
   msg = tonumber(string.sub(msg, 9, 12)) -- Read code from 'HTTP/1.0 XXX'
   if msg >= 200 and msg < 300 then
      txn.set_var(txn,"txn.request_verified",true)
   else
      txn.set_var(txn,"txn.request_verified",false)
   end
end)

The variable set there is readable by haproxy, so the corresponding section of a frontend might look like this:

global
  lua-load /etc/haproxy/scripts/verify_request.lua
...
frontend somefrontend
    mode http

    http-request lua.verify_request
    http-request redirect code 302 location https://your.oryui.loginurl?redirect_to=https://%[hdr(host)]%[capture.req.uri] unless { var(txn.request_verified) -m bool }

    ...  
    use_backend somebackend

If request_verified is not set, the redirect sends the user to the authentication frontend,; the query parameter "redirect_to" is used there after successful authentication.

The lua script above could certainly be improved by using appropriate libraries for request and response handling.

In this setup every single request would need to be checked by oathkeeper, which should be improved. I will post an update when I have a solution.

[vinckr]

thanks for sharing 🙌
i hope this will be useful for someone else looking to use haproxy with oathkeeper 🙏

[mfreeman451]

Basically this works via a lua script for haproxy.

A basic script is described in the section "Verify a request with another service" of the documentation.

This script can be modified like this, assuming an oathkeeper-instance listens on the default API port:

core.register_action("verify_request", { "http-req" }, function(txn)
   local s = core.tcp()
   s:connect("127.0.0.1:4456")
   s:send("GET /decisions" .. txn.sf:path() .. " HTTP/1.1\r\n" .. txn.f:req_hdrs())
   local msg = s:receive("*l")
   -- connection failure
   if msg == nil then
      -- This leave txn.request_verified unset for potentially diffrent handling
      return
   end
 
   msg = tonumber(string.sub(msg, 9, 12)) -- Read code from 'HTTP/1.0 XXX'
   if msg >= 200 and msg < 300 then
      txn.set_var(txn,"txn.request_verified",true)
   else
      txn.set_var(txn,"txn.request_verified",false)
   end
end)

The variable set there is readable by haproxy, so the corresponding section of a frontend might look like this:

global
  lua-load /etc/haproxy/scripts/verify_request.lua
...
frontend somefrontend
    mode http

    http-request lua.verify_request
    http-request redirect code 302 location https://your.oryui.loginurl?redirect_to=https://%[hdr(host)]%[capture.req.uri] unless { var(txn.request_verified) -m bool }

    ...  
    use_backend somebackend

If request_verified is not set, the redirect sends the user to the authentication frontend,; the query parameter "redirect_to" is used there after successful authentication.

The lua script above could certainly be improved by using appropriate libraries for request and response handling.

In this setup every single request would need to be checked by oathkeeper, which should be improved. I will post an update when I have a solution.

Were you ever able to make any improvements ? I'm guessing maybe you were considering some kind of caching layer?

[meinrecht]

We do not use ory anymore.
This was not a site with too much traffic, so the solution here worked as is (or was).