Multiple JWT policies

Enforce gateway- or route-based JWT authentication for different routes by using multiple policies. For example, you might have use cases similar to the following:

For more information about JWTs, see the JWT overview and API docs.

You can apply a JWT policy at the destination or route level, but you cannot apply multiple JWT policies to the same destination or to the same route in a route table. If you try to apply multiple policies, only the policy that you created first takes effect. In general, you apply policies to routes to protect ingress traffic through the gateway, and to destinations to protect traffic within the service mesh. If you want to configure multiple providers for the same route, see Multiple JWT providers. For more information, see Applying policies.

If you import or export resources across workspaces, your policies might not apply. For more information, see Import and export policies.

Before you begin

This guide assumes that you use the same names for components like clusters, workspaces, and namespaces as in the getting started, and that your Kubernetes context is set to the cluster you store your Gloo config in (typically the management cluster). If you have different names, make sure to update the sample configuration files in this guide.

Follow the getting started instructions to:

  1. Set up Gloo Gateway in a single cluster.
  2. Deploy sample apps.
  3. Configure an HTTP listener on your gateway and set up basic routing for the sample apps.

Configure JWT policies

Create a JWT policy for each route that requires JWT authentication.

The following example is for a basic JWT policy that uses a local JWT issuer and inline public key. The policy does the following:

  • Enables JWT authentication for the selected route.
  • Configures the https://dev.example.com issuer.
  • Adds the value of an org claim from the JWT payload to an X-Org header in the request, if present.
  • Adds the value of an email claim from the JWT payload to an X-Email header in the request, if present.
  • Checks requests by using the token found in the X-Auth header with the prefix Bearer <token>, or in a query parameter auth_token=<token>. Note that if a request has both the header and query parameter, both tokens must be valid for Gloo Gateway to accept the request.
The following example is for a basic JWT policy that uses a local JWT issuer and inline public key. The policy does the following:

  • Enables JWT authentication for the selected route.
  • Configures the https://login.example.com issuer.
  • Adds the value of an org claim from the JWT payload to an X-Org header in the request, if present.
  • Adds the value of an email claim from the JWT payload to an X-Email header in the request, if present.
  • Adds the value of a scope claim from the JWT payload to an X-Scope header in the request, if present.
  • Checks requests by using the token found in the X-Auth header with the prefix Bearer <token>, or in a query parameter auth_token=<token>. Note that if a request has both the header and query parameter, both tokens must be valid for Gloo Gateway to accept the request.

Review the following table to understand this configuration. For more information, see the API docs.

Setting Description
applyToRoutes Use labels to configure which routes to apply the policy to. This example label matches the app and route from the example route table that you previously applied. If omitted, the policy applies to all routes in the workspace.
phase Set when to apply the JWT filter in the request chain, either before (preAuthz) or after (postAuthz) authorization to have access to the JWT token. You can also set the priority if you have multiple policies in the same phase. The lowest numbered priority is run first. For more information, see Phase considerations. This example sets no priority, so the default value of zero is used.
providers Enter a name for the provider to help you map the provider when viewing logs to debug. The provider name does not affect the policy's behavior and cannot be used by other resources to select the policy.
claimsToHeaders Optionally set the claims from the JWT payload that you want to extract and add as headers to the request before the request is forwarded to the upstream destination. This example extracts the same two org and email claims and adds them as headers for both providers. The login-example also has an additional scope claim.
claimsToHeaders.append Enter a boolean value to add a claim's value if the header exists in the request. Use true to append the claim's value to the header, and false to overwrite any existing value in the header.
claimsToHeaders.claim Enter the name of the claim in the JWT payload to get the value for the header.
claimsToHeaders.header Enter the request header that the value of the claim is copied to.
issuer Optionally, set the JWT issuer, usually as a subdomain of a URL or email address. If set, the iss field in the JWT token must match this field, or else the request is denied. If unset, the iss field in the JWT token is not checked. In this example, the issuer is set to a unique URL per provider, https://dev.example.com or https://login.example.com.
keepToken This value is set to true so that the JWT is kept in the request after verification. This way, other policies can use the JWT information as needed.
local Provide the PEM-formatted public key to verify the JWT token. In this example, the public key is written inline to the policy for testing purposes. For production scenarios, you can set a remote reference to your JSON Web Key Set (JWKS) server instead of this local setting.

Try out multiple JWT policies

For quick testing, you can use sample keys with dev-example and login-example JWTs. For more details about the sample JWT, see the GitHub readme.

  1. Apply the JWT policy with the dev-example provider for the httpbin app. For more information about this policy, see the configuration example.

    kubectl apply -f https://gist.githubusercontent.com/artberger/674bab05350c9a048303cc7daaffe730/raw/daf7d9b64e5e9ecf309f17123e01f5a6cbb6c7eb/jwt-policy-basic.yaml
    
  2. Create another JWT policy with the login-example provider for the ratings app. For more information about this policy, see the configuration example.

    kubectl apply -f https://gist.githubusercontent.com/artberger/a69e3d405457ae9a3ac2ad1838937b86/raw/04de8f1042ab8d63b63e6781d1508e61163f4133/jwt-policy-basic-login.yaml
    
  3. Send a request to the httpbin app without any authentication. Notice that your request is denied with a 401 error.

    curl -vik -H "X-httpbin: true" --resolve www.example.com:80:${INGRESS_GW_IP} http://www.example.com:80/get
    
    curl -vik -H "X-httpbin: true" --resolve www.example.com:443:${INGRESS_GW_IP} https://www.example.com:443/get
    
    Example output:

    HTTP/1.1 401 Unauthorized
    www-authenticate: Bearer realm="http://www.example.com/get"
    ...
    Jwt is missing
    
  4. Get a sample JWT that is preconfigured to meet the validation requirements that you set in the JWT policy for the dev-example provider.

    TOKEN=$(curl https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/gloo-gateway/jwt/dev-example.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -
    

    Example output:

    {"iss":"https://dev.example.com","exp":4804324736,"iat":1648651136,"org":"internal","email":"dev1@solo.io","group":"engineering","scope":"is:developer%  
    
  5. Try the request to the httpbin app again, this time with your dev-example token. Notice that your request is now accepted!

    curl -vik -H "X-Auth: Bearer ${TOKEN}" -H "X-httpbin: true" --resolve www.example.com:80:${INGRESS_GW_IP} http://www.example.com:80/get
    
    curl -vik -H "X-Auth: Bearer ${TOKEN}" -H "X-httpbin: true" --resolve www.example.com:443:${INGRESS_GW_IP} https://www.example.com:443/get
    
    In the example output you get back a 200 response. You also can see the X-Email and X-Org headers that you appended in the claimsToHeaders section of the policy.

       HTTP/1.1 200 OK 
       ...
       {
         "args": {}, 
         "headers": {
           "Accept": "*/*", 
           "Host": "www.example.com", 
           "X-Email": "dev1@solo.io", 
           "X-Envoy-Attempt-Count": "1", 
           "X-Envoy-Decorator-Operation": "httpbin.default.svc.cluster.local:8000/*", 
           "X-Envoy-Internal": "true", 
           "X-Httpbin": "true", 
           "X-Org": "internal"
         },
       
  6. Send a request to the ratings app without authentication. Notice that your request is denied with a 401 error.

    curl -vik --resolve www.example.com:80:${INGRESS_GW_IP} http://www.example.com:80/ratings/1
    
    curl -vik --resolve www.example.com:443:${INGRESS_GW_IP} https://www.example.com:443/ratings/1
    
    Example output:

    HTTP/1.1 401 Unauthorized
    www-authenticate: Bearer realm="http://www.example.com/get"
    ...
    Jwt is missing
    
  7. Get another sample JWT that is preconfigured to meet the validation requirements that you set in the JWT policy for the login-example provider.

    TOKEN_LOGIN=$(curl https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/gloo-gateway/jwt/login-example.jwt -s) && echo "$TOKEN_LOGIN" | cut -d '.' -f2 - | base64 --decode -
    

    Example output:

    {"iss":"https://login.example.com","exp":4804324736,"iat":1648651136,"org":"external","email":"user2@example.com","group":"user","scope":"is:reader%  
    
  8. Try the request to the ratings app again, this time with your login-example token. Notice that your request is now accepted!

    curl -vik -H "X-Auth: Bearer ${TOKEN_LOGIN}" --resolve www.example.com:80:${INGRESS_GW_IP} http://www.example.com:80/ratings/1
    
    curl -vik -H "X-Auth: Bearer ${TOKEN_LOGIN}" --resolve www.example.com:443:${INGRESS_GW_IP} https://www.example.com:443/ratings/1
    

    In the example output you get back a 200 response.

    HTTP/1.1 200 OK 
    ...
    * Connection #0 to host www.example.com left intact
    {"id":1,"ratings":{"Reviewer1":5,"Reviewer2":4}}%   
       
  9. Optional: Clean up the resources that you created.

    kubectl -n bookinfo delete jwtpolicy jwt-policy-ratings
    kubectl -n httpbin delete jwtpolicy jwt-policy