Support Claims based validation and routing

[jasonwilliams14]

NGINX Ingress controller supports dynamically fetching public keys from IdP for JWT validation.

For users that have a requirement to validate specific claims in a JWT token or to perform routing based on a claim, this will allow the capability to inspect JWT tokens for specific claims. By inspecting these claims, customers can further take action on claims inside the token, or claims missing from a JWT token, giving them powerful routing capabilities based on a JWT token.

A few new items will need to be added to NGINX Ingress controller.
These include:

• we need to add the variable $jwt_payload for enhanced capabilities.
• We also need to add the $jwt_ as supported variable options when using match and conditions
• using auth_jwt_require to do claims validation/routing.

NGINX Ingress controller can be configured to look for specific claims in a JWT token

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: cafe
spec:
  host: cafe.example.com
  tls:
    secret: cafe-secret
  gunzip: on
  upstreams:
  - name: tea
    service: tea-svc
    port: 80
 - name: coffee
   service: coffee-svc
   port: 80
 routes:
 - path: /coffee
    matches:
     - conditions:
       - variable: $jwt_client_id
         value: 05
  action:
    pass: coffee

Documentation on VirtualServer.Routes.path.matches.conditions

Prototype policy:

apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: jwt-policy
spec:
  jwt:
    realm: MyProductAPI
    token: $http_token
    jwksURI: http://keycloak.default.svc.cluster.local:8080/realms/jwks-example/protocol/openid-connect/certs
    keyCache: 1h
    auth_require: $jwt_client_id $valid_issuer ### These are claims we can we can require for JWT tokens

In the prototype above, we can enforce a number of different claims with auth_require.
In the virtualserver resource, wee can use match to look for specific $jwt_client_id and a defined value and then proxy to the backend application.
We can further enhance this by sending back specific HTTP codes (401 or 403) if a claim is empty or has the incorrect value.

[cpuengr949]

It would also be nice to be able to log any response code from the IdP or login error for troubleshooting purposes.

[brianehlert]

An example:

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: cafe
spec:
  host: cafe.example.com
  http-snippets: |
    map $jwt_claim_iss $valid_jwt_iss {
    "<ISSUER>" 1;
    }
    auth_jwt_require $valid_jwt_iss;
...