Multiple named AuthServices

Support multiple named AuthServices and enable them on a per route mapping configuration. Would also unlock related issue: https://github.com/datawire/ambassador/issues/174

For example, configuring multiple AuthServices:

apiVersion: ambassador/v0
kind: AuthService
name: simple-auth
auth_service: "example-auth:3000"
---
apiVersion: ambassador/v0
kind: AuthService
name: other-auth-strategy
auth_service: "external-auth:8080"

And configuring routes:

apiVersion: ambassador/v0
kind:  Mapping
name:  qotm_cloud_mapping
prefix: /qotm/
rewrite: /qotm/
service: demo.getambassador.io
authentication: simple-auth
headers:
  x-demo-mode: cloud
---
apiVersion: ambassador/v0
kind:  Mapping
name:  qotm_local_mapping
prefix: /qotm/
rewrite: /
service: qotm
authentication: other-auth-strategy
headers:
  x-demo-mode: local
---
apiVersion: ambassador/v0
kind:  Mapping
name:  qotm_host_mapping
prefix: /qotm/
rewrite: /
service: httpbin.org:80
headers:
  x-demo-mode: host
host: httpbin.org
host_rewrite: httpbin.org
# No authentication strategy

Therefore, not all request methods will be proxied to an auth service, and we can select which auth service to use for dynamic routes.

[owais]

This is what I was expecting Ambassador to have after experiencing the “self service” style configuration for routing. How auth currently works goes totally against the self service ideology IMO. Right now, all teams/individuals hav to ship changes to two independent services (their service + auth service) whenever they need to change how their service is protected. Also, multiple teams will end up contributing to the same auth service and the auth service might end up being much more complex than it would make sense as business logic might creep in to the auth service handlers.

[travisghansen]

I’m putting the final touches on envoy grpc support within the project as well if that’s helpful to anyone 😃