Ambassador: External Authentication supports Json Web Tokens (JWT)

Created on 12 Jun 2017  Â·  19Comments  Â·  Source: datawire/ambassador

Ambassador needs to support Json Web Token ("JWT") an an authentication mechanism.

Information we need to collect:

  • Which algorithms?
  • Does it need to handle authorization as well as authentication (e.g. checking that the requested resource can be accessed with the claims attached to the JWT)

Outputs:

  • There is an External Authentication Service implementation with JWT
  • There is documentation for installing and configuring the JWT External Authentication Service.

Most helpful comment

Any update on this?

All 19 comments

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.

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:

  • A third party authentication service, such as the GitHub link you reference
  • Using Envoy's functionality, as Jeremy posted

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.

  • The middleware reads the JWT in the Authorization header
  • If the JWT is signed using the correct key, then it puts the payload in a header in the request (X-Jwt-Payload, by default)
  • If the JWT is invalid or not signed properly, then the header is left empty.
  • All requests return 200 OK

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.

Was this page helpful?
0 / 5 - 0 ratings