Support header and cookie mutators in Istio based JWT handler

[strekm]

Description

Based on POC implement header and cookie mutators for Istio based JWT handler. Implementation should be the same as in ORY oathkeeper. Other mutators: id_token and hydrator should in error message. Configuration should not change.

ACs:

• mutator configuration validated
• only header and cookie are supported in this task
• implementation for other types of handlers should not change
• Istio JWT integration test enhanced

Reasons

Provide same functionality for mutators as ORY oathkeeper

DoD:

• provide documentation
  - [ ] publish release notes and What's New updates for Kyma customers
• provide unit tests
• provide integration test
  - [ ] verify Get started guides
  - [ ] verify resource limits
• followup issue
  - [ ] create release and bump in kyma

Attachments
https://www.ory.sh/docs/oathkeeper/pipeline/mutator
depends on: #212
part of: #30

PR

• Add mutators for Istio JWT access strategy #269

[triffer]

Validation

Validations that we need to discuss:

• Should it be allowed to set an empty header or cookie value, e.g. to reset it.
  -> We should allow it if it's allowed by VS

  rules:
    - path: /cookies
      methods: ["GET"]
      mutators:
        - handler: cookie
          config:
            cookies:
              "a-cookie": ""

• Should we validate that only one mutator handler of each type is allowed, so it's not possible to have a configuration like this:
  -> Handlers should be unqiue

  rules:
    - path: /cookies
      methods: ["GET"]
      mutators:
        - handler: cookie
          config:
            cookies:
              "a-cookie": "a"
        - handler: cookie
          config:
            cookies:
              "b-cookie": "b"

Cookie handling

In the PoC the cookies are defined as set HeaderOptions. This will overwrite the existing Cookie header. The behaviour of the Ory cookie mutator reads like it's just adding cookie values. Following the docs it looks like that we can achieve the same for Istio if we use the add HeaderOperations instead.

Support in other handlers

implementation for other types of handlers should not change

• noop and oauth2_introspection will support mutators in access_rule
• jwt will support mutators in virtual service
• allow doesn't support mutators

[triffer]

Handling of existing headers and cookies

Ory overwrites headers and cookie.

The default behaviour of Istio Add in HeaderOperations will add the header value comma-separated if it already exists.

Header

Sending request to path with header mutator for X-Test: "mutator-value"

      mutators:
        - handler: header
          config:
            headers:
              x-test: "mutator-value"

curl -ik https://httpbin.local.kyma.dev/headers -H "X-Test: A"

The request will have the following header set
Ory
X-Test: mutator-value

Istio Add
X-Test: A,mutator-value

Istio Set
X-Test: mutator-value

Cookie

Sending request to path with cookie mutator for X-Test: "mutator-value"

      mutators:
        - handler: cookie
          config:
            cookies:
              x-test: "mutator-value"

curl -ik https://httpbin.local.kyma.dev/headers --cookie "x-test=A;other-cookie=value"

The request will have the following header set
Ory
"Cookie": "x-test=mutator-value;other-cookie=value"

Istio Add
"Cookie": "x-test=A;other-cookie=value,x-test=mutator-value"

Istio Set
"Cookie": "x-test=mutator-value"

Istio custom handling for cookie

We could have a custom handling for Cookie header that will result in this: VirtualService config

    headers:
      request:
        set:
          Cookie: '%REQ(Cookie)%;x-test=mutator-value;x-test2=mutator2'

This will result in the cookie header to have duplicate cookie names:

"Cookie": "x-test=A;x-test=mutator-value;x-test2=mutator2"

and an unused ; if there is no cookie header sent

"Cookie": ";x-test=mutator-value;x-test2=mutator2"

References

HTTP RFC Field Lines and Combined Field Value

When a field name is only present once in a section, the combined "field value" for that field consists of the corresponding field line value. When a field name is repeated within a section, its combined field value consists of the list of corresponding field line values within that section, concatenated in order, with each field line value separated by a comma.

HTTP/1.1 RFC Message Headers

Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.

-> Allows multiple headers with the same value if they can be appended, but also one header with multiple comma-separated fields.

HTTP/2 RFC 9113 Compressing the Cookie Header Field

The Cookie header field [COOKIE] uses a semicolon (";") to delimit cookie-pairs (or "crumbs"). This header field contains multiple values, but does not use a COMMA (",") as a separator, thereby preventing cookie-pairs from being sent on multiple field lines (see Section 5.2 of [HTTP]).

HTTP State Management Mechanism RFC 6265 The Cookie Header

When the user agent generates an HTTP request, the user agent MUST NOT attach more than one Cookie header field.

Decision

We decided to use the Set logic for headers and cookies, because for headers it's the same way handled in Ory and for cookies it's the only way to generate a valid cookie header.