Ambassador needs to support Json Web Token ("JWT") an an authentication mechanism.
Information we need to collect:
Outputs:
My company is evaluating service meshes and currently uses JWTs with NGNIX to listen on every request to update and validate JWTs. Would this mean that ambassador would be able to do something similar to NGINX's Authentication Based on Subrequest?
We just released Ambassador 0.9.0 today, which supports an external authentication service (see http://www.getambassador.io/user-guide/mappings.html#external-authentication) for details. Ambassador does not currently natively support JWT (that's what this issue is about).
Given the support for an external authentication service, does that meet your needs? If not, specifics about what additional support you would need would be great!
The external auth service gets enough information to do this kind of check, yes. As Richard notes, knowing more about the specifics of how you use JWT (which signing method, etc) would be interesting too!
Ambassador sends a POST request to the External Auth, but my use case sends a GET request to my external auth. Would this be possible to configure?
@ethanrubio for some reason, GitHub lost your comment (I got it in email). This isn't supported today, but we could easily add it. I've opened https://github.com/datawire/ambassador/issues/73 to track this issue.
Check out one I just made.
Whoa! That's great, @kminehart -- we'll check it out! :)
It's not perfect, I just made it yesterday/today. Any feedback would be appreciated.
Thanks! :)
@kminehart It might be worth including a sample Ambassador auth.yaml in your README -- is this what you use?
---
apiVersion: ambassador/v0
kind: Module
name: authentication
config:
auth_service: {whatever you need}
allowed_headers:
- "x-jwt-payload"
?
apiVersion: ambassador/v0
kind: Module
name: authentication
config:
auth_service: {whatever you need}
allowed_headers:
- "Authorization"
To my understanding, JWTs are by convention provided as Authorization: Bearer xxxxxxxxxx, so that's the only thing I left unconfigurable.
Ah, the allowed_headers are headers allowed to come from the auth service _back_ to Ambassador...
Ahhhh I see. Then yes. :)
my bad
One issue I encountered which may warrant creating a new issue is if I did not include a path prefix for the authentication module then it would put me in a redirect loop.
Here's some successful tests!
No JWT provided
user kminehart/ambassador-auth-jwt ‹master*› » curl -L -v -X POST ambassador.example.com
* Rebuilt URL to: ambassador.example.com/
* Trying ambassador.example.com...
* TCP_NODELAY set
* Connected to ambassador.example.com (ambassador.example.com) port 80 (#0)
> POST / HTTP/1.1
> Host: ambassador.example.com
> User-Agent: curl/7.56.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< content-type: text/plain; charset=utf-8
< x-content-type-options: nosniff
< date: Wed, 18 Oct 2017 18:10:42 GMT
< content-length: 77
< x-envoy-upstream-service-time: 0
< server: envoy
<
Unable to retrieve jwt from header 'Authorization' or cookie 'session_token'
* Connection #0 to host ambassador.example.com left intact
Completely wrong jwt provided
user kminehart/ambassador-auth-jwt ‹master*› » curl -L -v -X POST ambassador.example.com -H "Authorization: Bearer asdf"
* Rebuilt URL to: ambassador.example.com/
* Trying ambassador.example.com...
* TCP_NODELAY set
* Connected to ambassador.example.com (ambassador.example.com) port 80 (#0)
> POST / HTTP/1.1
> Host: ambassador.example.com
> User-Agent: curl/7.56.0
> Accept: */*
> Authorization: Bearer asdf
>
< HTTP/1.1 401 Unauthorized
< content-type: text/plain; charset=utf-8
< x-content-type-options: nosniff
< date: Wed, 18 Oct 2017 18:10:49 GMT
< content-length: 45
< x-envoy-upstream-service-time: 0
< server: envoy
<
token contains an invalid number of segments
* Connection #0 to host ambassador.example.com left intact
Environment variable CHECK_EXP = true, exp in token's payload < today's datetime (UTC) (aka token is expired)
user kminehart/ambassador-auth-jwt ‹master*› » curl -L -v -X POST ambassador.example.com -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImV4cCI6IjIwMTctMDgtMTdUMjE6MDA6MDBaIn0.q6I230AY0rZWrW1hEcPxAjUhbQ_Odh6JKl9iEA78Va0"
* Rebuilt URL to: ambassador.example.com/
* Trying ambassador.example.com...
* TCP_NODELAY set
* Connected to ambassador.example.com (ambassador.example.com) port 80 (#0)
> POST / HTTP/1.1
> Host: ambassador.example.com
> User-Agent: curl/7.56.0
> Accept: */*
> Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImV4cCI6IjIwMTctMDgtMTdUMjE6MDA6MDBaIn0.q6I230AY0rZWrW1hEcPxAjUhbQ_Odh6JKl9iEA78Va0
>
< HTTP/1.1 401 Unauthorized
< content-type: text/plain; charset=utf-8
< x-content-type-options: nosniff
< date: Wed, 18 Oct 2017 18:10:57 GMT
< content-length: 22
< x-envoy-upstream-service-time: 19
< server: envoy
<
This token is expired
* Connection #0 to host ambassador.example.com left intact
Token signed with different key
user kminehart/ambassador-auth-jwt ‹master*› » curl -L -v -X POST ambassador.example.com -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImV4cCI6IjIwMTctMDgtMTdUMjE6MDA6MDBaIn0.S7oY3ruCarDHkR0a_bSJ6Jz6LJs7-5fEsrMQCOjBnqg"
* Rebuilt URL to: ambassador.example.com/
* Trying ambassador.example.com...
* TCP_NODELAY set
* Connected to ambassador.example.com (ambassador.example.com) port 80 (#0)
> POST / HTTP/1.1
> Host: ambassador.example.com
> User-Agent: curl/7.56.0
> Accept: */*
> Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImV4cCI6IjIwMTctMDgtMTdUMjE6MDA6MDBaIn0.S7oY3ruCarDHkR0a_bSJ6Jz6LJs7-5fEsrMQCOjBnqg
>
< HTTP/1.1 401 Unauthorized
< content-type: text/plain; charset=utf-8
< x-content-type-options: nosniff
< date: Wed, 18 Oct 2017 18:11:42 GMT
< content-length: 21
< x-envoy-upstream-service-time: 17
< server: envoy
<
signature is invalid
* Connection #0 to host ambassador.example.com left intact
Valid token (but 404 on my service)
user kminehart/ambassador-auth-jwt ‹master*› » curl -L -v -X POST ambassador.example.com -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImV4cCI6IjIwMTctMTEtMTdUMjE6MDA6MDBaIn0.asmHH-xZdV6JdaUOFttHIe4Vn5EBANHJFKKBozVzxzk"
* Rebuilt URL to: ambassador.example.com/
* Trying ambassador.example.com...
* TCP_NODELAY set
* Connected to ambassador.example.com (ambassador.example.com) port 80 (#0)
> POST / HTTP/1.1
> Host: ambassador.example.com
> User-Agent: curl/7.56.0
> Accept: */*
> Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImV4cCI6IjIwMTctMTEtMTdUMjE6MDA6MDBaIn0.asmHH-xZdV6JdaUOFttHIe4Vn5EBANHJFKKBozVzxzk
>
< HTTP/1.1 404 Not Found
< date: Wed, 18 Oct 2017 18:12:11 GMT
< server: envoy
< content-length: 0
<
* Connection #0 to host ambassador.example.com left intact
Same thing but with PUT
user kminehart/ambassador-auth-jwt ‹master*› » curl -L -v -X PUT ambassador.example.com -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImV4cCI6IjIwMTctMTEtMTdUMjE6MDA6MDBaIn0.asmHH-xZdV6JdaUOFttHIe4Vn5EBANHJFKKBozVzxzk"
* Rebuilt URL to: ambassador.example.com/
* Trying ambassador.example.com...
* TCP_NODELAY set
* Connected to ambassador.example.com (ambassador.example.com) port 80 (#0)
> PUT / HTTP/1.1
> Host: ambassador.example.com
> User-Agent: curl/7.56.0
> Accept: */*
> Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImV4cCI6IjIwMTctMTEtMTdUMjE6MDA6MDBaIn0.asmHH-xZdV6JdaUOFttHIe4Vn5EBANHJFKKBozVzxzk
>
< HTTP/1.1 404 Not Found
< date: Wed, 18 Oct 2017 18:12:45 GMT
< server: envoy
< content-length: 0
<
* Connection #0 to host ambassador.example.com left intact
Envoy recently added JWT verification.
Has anyone tried using that with Ambassador yet?
On GKE, IAP provides an authorization service and can automatically redirect requests. All we need to do with Ambassador is ensure there is a valid JWT to ensure traffic went through IAP.
I think JWT would be a great feature for Ambassador! I noticed a new repo was created for it specifically:
https://github.com/datawire/ambassador-auth-httpjwt
Are guys looking for collaborators for it?
Best,
TM
We'd love to have some help! If you're interested, even some research into a general design proposal would be helpful. Off the top of my head, there are two possibilities for implementation:
The Envoy functionality seems like it would be nicer, but haven't done any deep research.
Just for some insight into a work model we have now:
The strategy we went with kept the whole thing pretty simple.
Authorization headerX-Jwt-Payload, by default)I leave it up to the service to decide whether or not the request is valid based on the information in the JWT payload, and whether or not the JWT payload even exists.
I'd like to see how it'd be done if Envoy handled JWTs.
For Envoy there is a little process flow description in https://github.com/istio/proxy/tree/master/src/envoy/http/jwt_auth
Any update on this?
This is now supported in Ambassador Pro, or, as pointed out above, is supported via the AuthService API.
Most helpful comment
Any update on this?