Disable authorisation on preflight OPTIONS request in HAProxy

authenticationcorshaproxyhttp

We have a HAProxy setup which has basic auth on some of our backends. We now want to enable CORS requests to our backends but this is failing for those with basic auth enabled.
When CORS makes it preflight OPTIONS request it does not include the auth header and thus it fails and so the request fails.

Is there a way of allowing the OPTIONS request without authrisation but mandating it for all other requests?

Our haproxy.cfg has the following sections relevant to this:

#User lists used to enforce HTTP Basic Authentication
...
userlist ul_hyknpj6tb-uakf5isp
  user fred password $6$H/M21cSsvXn$jlEZQV7QL/clhV7JtZkAQf34QAPfZq5sE.zLE.M3gi4K1DV5J6ppc.e1JAOP0CtVxM0.n157llg5tsTp0gPFj1
....
backend b_term_hyknpj6tb-uakf5isp
  mode http
  balance roundrobin
  option forwardfor
  stick-table type ip size 1k expire 30s store bytes_in_rate(1s),bytes_out_rate(1s)
  tcp-request content track-sc2 src
  tcp-request inspect-delay 200ms
  tcp-request content accept if ! too_many_req
  tcp-request content accept if WAIT_END  
  rspadd Strict-Transport-Security:\ max-age=16000000;\ includeSubDomains
  acl is_auth http_auth(ul_hyknpj6tb-uakf5isp)
  http-request auth realm iiboc if !is_auth
  server node_hyknpj6tb-uakf5isp_1000 192.31.11.70:7843 check ssl verify required crt fred/fred-internal.pem ca-file bob/bob-internal.cert.pem 
.....

Best Answer

You can allow the OPTIONS request without authorization by handling those requests in a different backend that does not require authenticatoin:

frontend fe_main
    acl options_method method OPTIONS
    use_backend be_options if options_method

Where be_options is a backend similar to b_term_hyknpj6tb-uakf5isp but without http-request auth realm iiboc if !is_auth

Related Solutions

Ssl – HAProxy SSL Farm Options

Kyle,

if you only need fail-over for the SSL part and not load balancing, here's what I suggest. You install haproxy + keepalived + stunnel (patched) on two nodes. Keepalived owns the service address and checks for the presence of the stunnel and haproxy processes to compute its weight so that the node in best shape is the master. Stunnel receives the traffic on port 443 and locally forwards it to haproxy on any port you like. In order for haproxy to log the client's IP address, you need the x-forwarded-for patch for stunnel (you can find it on my site). You'll then tell haproxy to log the x-forwarded-for header.

There is a limitation however. If you support HTTP keep-alive, then stunnel will only add the x-forwarded-for header once, which is a bit problematic. At Exceliance, we've started working on a patch to forward the connection parameters from stunnel to haproxy instead of playing with the x-forwarded-for. That way, haproxy believes it gets its connection from the real client. If you're interested, tell me, we can send it to you once it's complete.

How to add basic auth to an apache proxy while using CORS headers

I solved this by always allowing OPTIONS-requests. Those Request only serve as a "ping" to check if the server is there.

<Proxy *>
  Order deny,allow
  Allow from all

  AuthType Basic
  AuthBasicProvider file
  AuthUserFile /path/to/passwords

  # This allows OPTIONS-requests without authorization
  <LimitExcept OPTIONS>
    Require valid-user
  </LimitExcept>

</Proxy>

A more clean approach could be to change grafana and how the requests are made, but this solves the immediate problem without opening new ones.

This does currently not make things worse from a security point of view:

OPTIONS currently does not have a body to reveal more information
OPTIONS is idempotent in the sense that it always does nothing
The mere existence of the server can also be checked with a heavier GET /.
All other HTTP-methods but OPTIONS are password-protected

Related Topic