Generic auth filter

[xiaomi-tc]

Just like in nginx, I can set ngx_http_auth_request_module module to implement authorization when clients connecting in with a bypass authorization server. Does envoy support this or will support? If not ,what shall I do?

[mattklein123]

I'm sorry but I don't understand what you are asking. Can you clarify what feature you want and/or what changes are required to what is currently implemented?

[PiotrSikora]

Translation: ngx_http_auth_request_module does a lookaside HTTP request, result of which (2xx or 403) decides whether or not the request should be processed / proxied.

[mattklein123]

Yes, async request processing is possible in a filter via the AsyncClient mechanism. We have 2 auth filters at Lyft that work this way. There are other examples in the public code base. Beyond that, I'm not sure if this is an ask for a particular auth protocol being implemented.

[markschmid]

We also use the ngx_http_auth_request_module mechanism of nginx. In case of a positive auth result (2xx), we inject custom HTTP headers (e.g. user id etc.) for the service to work with.
Is custom header injection based on the result of a subrequest possible in envoy? Any chance such a generic "auth subrequest" filter could be one of the standard filters of envoy?

[jwfang]

+1 for this.

it's nice to have a generic auth filter

[jwfang]

@markschmid

you can take a look at the istio project's mixer filter, from their istio/proxy project.

[mattklein123]

@jwfang @markschmid if there is a generic way to do an auth filter that is useful to folks, I'm totally open to it. Feel free to drop a proposed design here. We have multiple auth filters internally at Lyft, but they contain Lyft specific functionality so it's not reasonable to open source them. I will reopen this issue to track seeing if there is a way to do a generic filter.

[markschmid]

Thanks!

OK so I propose the following generic authentication mechanism for Envoy, implemented as a filter.
It would basically mimic the "client authorization based on the result of a subrequest" mechanism of the nginx ngx_http_auth_request_module module [1], which is, in a nutshell:

Authenticate each request with an external auth service. To perform authentication, an HTTP subrequest is sent to an external auth service where the subrequest is verified. If the subrequest returns a 2xx response code, access is allowed, if it returns 401 or 403, access is denied. This generic way of authentication would allow for implementing various authentication schemes.

This is the proposed mechanism step by step:

1. Envoy receives a request (HTTP)
2. In order to authenticate the request, Envoy performs an HTTP subrequest to an arbitrary auth service which verifies the subrequest
3. If the auth service responds with a 2XX status code, access is allowed. Envoy further "processes" the original request (e.g. apply next filter, proxy onward etc.)
4. Optionally: Inject HTTP header parameters received by the subrequest response into the original request (e.g. to supply user identity or other data)
5. If the auth service responds with status codes 401 or 403, access is denied. Envoy sends a HTTP reponse to the original request with status code 401 (or 403 respectively).
6. Any other status code sent by the auth service is considered an error

Possible filter configuration

{
  "type": "decoder", // unsure, maybe "both"?
  "name": "auth_request",
  "config": {
    "inject_headers": ["X-Authrequest-Userid", "X-Authrequest-Foo", "X-Authrequest-Bar", ...], // headers received from the auth service response that need to be injected into the verified request
    "timeout": "...", // maybe a configurable timeout in ms for the auth service response (?)
  }
}

Notes:

• Authentication subrequest (step 2) should include the complete header of the request of step 1 (but not the body)
• The auth service should probably be configured as a cluster in the clusters array of the cluster_manager

Additional reading about the nginx module in question can be found in [2] and finally, I think, the repository containing the source of that nginx module is found in [3]
I hope this makes at least some sense. As I've only just started looking into envoy a few days ago, I might have missed existing options/concepts etc.

In any case, I'd be happy to further clarify or help in any other way for getting such a filter in envoy!

[1] http://nginx.org/en/docs/http/ngx_http_auth_request_module.html
[2] https://www.nginx.com/resources/admin-guide/restricting-access-auth-request/
[3] https://github.com/PiotrSikora/ngx_http_auth_request_module

[mattklein123]

In general this seems reasonable to me (there are some details to sort out in terms of what should be configurable, etc.). If someone wants to sign up to implementing the filter let me know. It's not difficult and can be modeled after existing filters.