solo-io / gloo

The Feature-rich, Kubernetes-native, Next-Generation API Gateway Built on Envoy
https://docs.solo.io/
Apache License 2.0
4.04k stars 431 forks source link

In JWTStaged, when allowMissingOrFailed: true then claimsToHeaders is not applied to the upstream request #8701

Open edubonifs opened 10 months ago

edubonifs commented 10 months ago

Gloo Edge Product

Enterprise

Gloo Edge Version

1.15

Is your feature request related to a problem? Please describe.

When I set allowMissingOrFailed: true then claimsToHeaders is applied to the upstream request as expected. When I set allowMissingOrFailed: true then claimsToHeaders is not applied. You need to be able to set allowMissingOrFailed: true to combine a JWTStaged AfterExtAuth with a customExtAuth.

we have a customer that wants to route based on the claims of a jwt which was issued by a custom extauth. So extauth issues jwt, and then we need to perform jwtStaged afterExtAuth in order to do claimToHeaders, but they don't want to perform verification for the jwt, just claimToHeaders. However, if we set allowMissingOrFailed: true, claimToHeaders is not done.

I saw a github issue for GM that seems exactly the same case: https://github.com/solo-io/gloo-mesh-enterprise/issues/10588

Describe the solution you'd like

When I set allowMissingOrFailed: true then claimsToHeaders is applied even though the request didn't pass, as we might don't want to do verification, but just claimToHeaders.

If this implemented in GPmaybe it is easier to implement it in GE

Describe alternatives you've considered

No response

Additional Context

For reproducing, just create a VirtualService with stagedJwt using httpbin:

spec:
  virtualHost:
    domains:
    - '*'
    options:
      jwtStaged:
        afterExtAuth:
          allowMissingOrFailedJwt: false
          providers:
            solo:
              claimsToHeaders:
              - claim: org
                header: org
              issuer: solo.io
              jwks:
                local:
                  key: |
                    -----BEGIN PUBLIC KEY-----
                    MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1xJGM/DTuzSt9TjSNTmP
                    OLUJgD6Ayhq6mwombExLI9/jS08Ryel6UMtQ8rJubFJ0tZ2tMTxZEp7RhviH6y1D
                    bRVaVgqIKF5AEQy6R2mWDOZ52XRWpZ374u6WNXivA6CDRwScKNfTe+xIzcPfnj8o
                    MWV8zXyDPw07CGkAiOlV4wOuz/qXm4tbJnc4snBY3Wqn41Z3oHy2LHY7bQLDqohu
                    masMj874wLznQFru/dYChdCUlcSfxVNivzTkOXDkH+/0Ie2OuR+44iodH2Dp758P
                    7leIfUHJmMCxN7RVr7bntn0jcQr593AjIP26lQWsMrdNjRRyp0JU5umrc4w09WVb
                    QwIDAQAB
                    -----END PUBLIC KEY-----
              tokenSource:
                headers:
                - header: x-token
                queryParams:
                - token
    routes:
    - matchers:
      - prefix: /
      routeAction:
        single:
          upstream:
            name: httpbin-httpbin-8000
            namespace: gloo-system

And check that if allowMissingOrFailedJwt is false, we can see the org header:

  "headers": {
    "Accept": "*/*", 
    "Host": "ae5ed68abb7ed49818e00ef588de711c-1834007428.us-east-1.elb.amazonaws.com", 
    "Org": "solo.io", 
    "User-Agent": "curl/7.85.0", 
    "X-Envoy-Expected-Rq-Timeout-Ms": "15000"
  },

But if I have allowMissingOrFailedJwt is true, I don't see the header any more:

  "headers": {
    "Accept": "*/*", 
    "Host": "ae5ed68abb7ed49818e00ef588de711c-1834007428.us-east-1.elb.amazonaws.com", 
    "User-Agent": "curl/7.85.0", 
    "X-Envoy-Expected-Rq-Timeout-Ms": "15000"
  },
SantoDE commented 10 months ago

It could be fixed with the new version of ext-auth, see the issue linked above. PTAL @edubonifs

edubonifs commented 8 months ago

Hi, I just tested in GE enterprise 1.15.6 and I am still not able to extract the claim as a header when the JWT validation fails

huzlak commented 3 months ago

Still doesn't work in GEE 1.16.4. IIRC VirtualService JWT option is translated to jwt filter directly in envoy so new extauth version doesn't change the behavior.

DuncanDoyle commented 3 weeks ago

This was fixed a while ago in GME with this PR: https://github.com/solo-io/gloo-mesh-enterprise/pull/11113

This is a Gloo Gateway <-> Gloo Mesh Gateway feature parity concern.