JWT authentication on specific method

Nice to meet you all.

Due to some interop requirements with a third-party app, I have designed an API as follows:

  • POST /v1beta1/stores (no Bearer auth required, an alternative mechanism is used)
  • GET /v1beta1/stores (Bearer auth required)

I’m precious about keeping paths consistent, so I’m wondering what options are available to enforce an origin policy only on the GET method?

I was thinking to split out authenticated and non-authenticated endpoints into different service ports/matching rules, using the policy ports target selector and creating two separate policies. Is this sane? Or am I potentially missing a jwt triggerRules option that can be used for the http method?

Thanks :smiley:

You’re not missing anything from the triggerRule, it currently only supports path.

For your requirement, Instead of modifying your application (this is also possible if you think it gives you a better architecture), you can also use Istio authorization policy to do the fine-grained access control based on methods or paths.

You can apply the following policies to do so, the trick here is to set originIsOptional to true delegate the access control to the authorization layer:

apiVersion: authentication.istio.io/v1alpha1                                  
kind: Policy                                                                  
  name: jwt
  namespace: <your-service-namespace>
    - name: <your-service-name>
  originIsOptional: true
    - jwt:
  principalBinding: USE_ORIGIN

The following authZ policy requires JWT token on GET method only:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
 name: authz
 namespace: your-service-namespace
 - to:
   - operation:
       methods: ["GET"]
       paths: ["/v1beta1/stores"]
   - key: request.auth.principal
     values: ["*"] // requires any valid JWT token
 - to:
   - operation:
       methods: ["POST"] // For POST, do not require JWT token
       paths: ["/v1beta1/stores"] 

With the new JWT policy and deny/exclude semantics in AuthZ policy, the above policy could be much simplified and also more flexible other requirements.