feat: Add support for header in rule matching

[a-manraj-pvotal]

Preflight checklist

• [X] I could not find a solution in the existing issues, docs, nor discussions.
• [X] I agree to follow this project's Code of Conduct.
• [X] I have read and am following this repository's Contribution Guidelines.
• [X] This issue affects my Ory Cloud project.
• [X] I have joined the Ory Community Slack.
• [X] I am signed up to the Ory Security Patch Newsletter.

Context and scope

We are generating from proto and internal configs versioned oathkeeper rules. Protobufv3 generates the code references from an :authority and :path perspective preventing us from modifying it. We are passing a version in a header to route to a specific version of a microservice with the autogenerated rule. As it stands oathkeeper is unaware of the specific header and the rules are not version specific and collide with one another.

Therefore we suggest leverage not only the URL for the oathkeeper rule but also a header for routing and security rules to be unique and apply correctly when a new rule version is generated. This can also happen if headers are used internally in REST for routing.

Goals and non-goals

We suggest adding an additional optional header configuration to the rule matching to become unique in Oathkeeper and Oathkeeper maester's configuration from a combination of URL and specific header containing possibly the service version.

The design

Modify api/decision.go, matcher.go and rule.go to take into account the optional new header for oathkeeper rule unicity. Modify the documentation and tests to clearly account for the new option.

APIs

No response

Data storage

No response

Code and pseudo-code

No response

Degree of constraint

No response

Alternatives considered

The alternative in REST would be to add the version into the URL, this solution can't be used when generating the :authority and :path in HTTP2/HTTP3 as it is controlled by the proto generation.