Add support for returning authenticated user

[lsiudut]

As for now, if oauth2_proxy is used only as authenticator, it doesn't return information about authenticated user. This patch introduces header X-Authenticated-User which is returned from proxy upstream. This way further user-based authorization is possible.

[jehiah]

@lsiudut I generally think oauth2_proxy should continue to be agnostic of the actual application that is being proxied/authenticated. Having oauth2_proxy set response headers with authentication seems to break that assumption and change that dynamic. I think responsibility for response headers should rest entirely on the proxied application.

I suggest that a better way to implement this would be to enable --pass-basic-auth and have your application behind oauth2_proxy copy X-Forwarded-Email request into X-Authenticted-Email response header.

[lsiudut]

I understand you completely and I was trying to make my solution this way. I thought that returning name of authenticated user is similar action as forwarding basic auth to application with difference, that we may perform some actions on http server level (nginx and lua authorization in this case). Unfortunately we have setup which makes inserting another proxy very difficult.

If you're finding this solution too invasive just close this PR.

[pawelgocek]

What would be good way to pass authentication data in use case of nginx auth_request directive?

[jehiah]

@pawelgocek can you expand upon your question? What are you trying to accomplish?

[lsiudut]

To pass information about authenticated user name/email to upstream. Right now it is possible when oauth2_proxy works as proxy, but when it's used as authenticator (for auth_request directive) we don't receive any information except authentication status (HTTP 202 or 401).

In our use case nginx is proxying directly to microservices and there's no easy way to inject oauth2_proxy between them. Also we can't use it before nginx, as not all endpoints are suppose to be covered by authenticator. auth_request directive is perfect for us, but we lack info about authenticated user name. We could try to make some hacky solution and proxy authenticated request back to nginx, but we'd like to avoid it.

[mbland]

Actually, this should be possible with the auth_request_set Nginx directive, something like:

auth_request_set $auth_user $upstream_http_x_authenticated_email;
proxy_set_header x-authenticated-email $auth_user;

See also: http://stackoverflow.com/questions/19366215/setting-headers-with-nginx-auth-request-proxy

[lsiudut]

Yes, but only if oauth2_proxy return X-Authenticated-Email in response for /auth request :). For now it's not returning such header. My patch adds exactly this functionality.

[jehiah]

@lsiudut @mbland ahh. thanks this context is helpful. When using nginx auth is a good argument for setting return parameters so that nginx can pass them upstream. Let me think this a little more.

[szibis]

+1

[rcoup]

This looks super-helpful for auth_request users, is there anything else that needs doing to get it landed? :)

[tamsky]

This still looks super-helpful for auth_request users (&& required for some grafana users).
Is there anything else that needs doing to get it landed?

[tamsky]

I noticed there were merge conflicts.
After resolving those, I noticed travis was busted.
Travis is now fixed in #299.
Travis build and tests now pass.

New pull request is #298

[caffeineshock]

We are currently using the auth_request directive as well which saves us a lot of nginx instances and configuration details for oauth2_proxy. So is there anything still blocking #298 or can we expect it to be merged soon? Otherwise we will have to bite the bullet and either switch to the branch containing the change or start using oauth2_proxy as an actual proxy.

[cndbain]

We are also using the auth_request directive and would like to use #298 if it were merged.

[ashkulz]

#319 has been merged, so this can be closed.