Traefik auth forward

[mvanderlee]

Behaves identical to /decisions except that it gets the url and method from the headers.
This allows integration with Traefik's ForwardAuth middleware.

Related issue

#263

Proposed changes

Add integration with Traefik by adding a new /auth_forward endpoint that behaves identical to /decisions except that it gets the url and method from the following headers:

• X-Forwarded-Uri
• X-Forwarded-Method

Checklist

• I have read the contributing guidelines
• I have read the security policy
• I confirm that this pull request does not address a security
  vulnerability. If this pull request addresses a security vulnerability, I
  confirm that I got green light (please contact
  security@ory.sh) from the maintainers to push
  the changes.
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation within the code base (if appropriate)
• I have documented my changes in the
  developer guide (if appropriate)

Further comments

I've copied the decision.go file, renamed where appropriate, and changed the rule matcher input. Found references to DecisionHandler and added the new AuthForwardHandler accordingly.
I've tested locally with this config https://gist.github.com/MVanderlee/2dba10f1ed6c869630eab27847bc2d12

The endpoint only has to support GET but wasn't sure how that's achieved.

Please review carefully as I'm not familiar with GoLang.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Michiel Vanderlee seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[mvanderlee]

I can't figure out how to get the CLA working. I have however accepted it

[mvanderlee]

Just realized that the URI is only the path. Would also need to get add these:

	xForwardedProto  = "X-Forwarded-Proto"
	xForwardedHost   = "X-Forwarded-Host"

and somehow combine them into a URL object for the Matcher to understand

[aeneasr]

Thank you for this PR. Obviously we'd like to avoid having one endpoint per proxy. Is there any other solution or workaround for this? If not, I think it would make sense to rewrite the decision endpoint and add e.g. /decision/generic, /decision/traefik - that ways it's really easy to target one individual service.

Regarding the CLA, I'll look into it - sometimes the thing is buggy.

[mvanderlee]

There is no alternative from Traefik's side. I agree with the decision endpoint rewrite.

[mvanderlee]

I've updated the paths, and now include the protocol and host in the matcher url.

[aeneasr]

We need to set up a redirect from /decisions/* (excluding "/decisions/generic(|/*)" and /decisions/traefik(|/*)) to /decisions/generic/$1 for backwards compatibility!

[mvanderlee]

I've handled this by simply relying on the middleware order.
This does present an issue for the metrics, and I'm not sure how to handle that.

[aeneasr]

Once the redirect is set up, I believe that all tests will pass again! :)

[aeneasr]

Sorry, accidental close.

[derekbar90]

Any update on the status of this ticket?

[aeneasr]

@MichielVanderlee are you still up for this contribution?

[pdaher]

@jmt-vanderlee do you still plan to go forward with this PR?

[derekbar90]

@jmt-vanderlee Are you still thinking of accepting the license agreement? Would love to see this hit production

[rdehouss]

Hi @mvanderlee, I see that your gist is not available anymore.
Do you have another one?
You could also update the README to include theTraefik compatibility + links to doc :)

Many thanks in advance!

[mrkwtz]

Thank you for this PR. Obviously we'd like to avoid having one endpoint per proxy. Is there any other solution or workaround for this? If not, I think it would make sense to rewrite the decision endpoint and add e.g. /decision/generic, /decision/traefik - that ways it's really easy to target one individual service.

Regarding the CLA, I'll look into it - sometimes the thing is buggy.

We like the idea to make the decisions endpoint more configurable (e.g. define the header from which it should source host, uri, etc).

We ran into the same issues with the nginx ingress controller and auth_request. Because we don't want to expose the decision endpoint via ingress we target the oathkeeper-api directly in the auth-url. However this leads oathkeeper to get his hostname as the host header (therefore it doesn't match the hostname in the rules anymore) and there is no way around this (when you want to keep using the "self-configurable" nginx controller).

[aeneasr]

I might be able to tackle this and provide a generic structure for adding proxy specific decision endpoints

[mvanderlee]

Proof of signing the CLA:

[aeneasr]

Thank you! The CLA is sometimes buggy :)

I take it the code is ready for review? :)

[aeneasr]

This looks pretty good :) Now we need some tests for the new functionality and also the legacy decision path! Also, the documentation needs to updated here and here also also anywhere where you find /decision :)

[aeneasr]

Superseded by #486