feat: Add support for header in rule matching#967
feat: Add support for header in rule matching#967m-guesnon-pvotal wants to merge 9 commits intoory:masterfrom
Conversation
Codecov Report
@@ Coverage Diff @@
## master #967 +/- ##
==========================================
+ Coverage 77.65% 77.78% +0.13%
==========================================
Files 80 80
Lines 3965 3980 +15
==========================================
+ Hits 3079 3096 +17
+ Misses 607 606 -1
+ Partials 279 278 -1
|
|
Formatting with npm run format to please the CI modified all the *.md file. This can be reverted if needed. |
aeneasr
left a comment
There was a problem hiding this comment.
Could you please revert all changes not related to this PR? :)
|
Done. However, this brought back the linter fail for CI. (I suspect current master could not pass the CI) |
|
@aeneasr any news for linter and the content of the PR itself ? |
|
Outside linting @aeneasr any changes required or discussion to alter ? |
aeneasr
left a comment
There was a problem hiding this comment.
Sorry for the super late review, my backlog is simply too big at the moment. I have a couple of questions for this PR and would be thankful if you could answer those
| // A map of HTTP headers. When ORY Oathkeeper searches for rules | ||
| // to decide what to do with an incoming request to the proxy server, it compares the HTTP headers of the incoming | ||
| // request with the HTTP headers of each rules. If a match is found, the rule is considered a partial match. | ||
| // For headers with values in array format (e.g. User-Agent headers), the rule header value must match at least one | ||
| // of the request header values. | ||
| // If the matchesUrl and matchesMethods fields are satisfied as well, the rule is considered a full match. |
There was a problem hiding this comment.
Wha is the difference between a partial and a full match?
There was a problem hiding this comment.
This is wording have taken from the comments on other fields.
My interpretation is that a partial match means you satisfied to one aspect of the rule. The incoming request has to be a (partial) match to all aspects of this rule in order to become a full match.
rule/rule.go
Outdated
| // For headers with values in array format (e.g. User-Agent headers), the rule header value must match at least one | ||
| // of the request header values. | ||
| // If the matchesUrl and matchesMethods fields are satisfied as well, the rule is considered a full match. | ||
| Headers map[string]string `json:"headers"` |
There was a problem hiding this comment.
As far as I understand, this is an AND match. So if all requirements are met from the rule, it will apply. Is that desired? Are there use cases for OR? And if so, how do we handle those? We can also only support AND for now but will nede to support OR most likely at some point, without breaking the config.
There was a problem hiding this comment.
At this point, the implementation only supports AND.
You have to match all headers specified in the rule. IMHO, an OR implementation would be overcomplicating things. It should just be a different rule. Headers are seen just like URLs are (although, it is true that URLs support wildcards).
There was a problem hiding this comment.
I think that using using OR is definitely a breaking change as it would potentially override normal oathkeeper rule matching and documentation with an optional routing header that was aimed at obtaining rule unicity per route with header (header : service aV1 to match a certain rule and header: service aV2 to match another rule and for both to live at the same time). Therefore i would recommend supporting only AND for now as it is meant only as an advanced configuration parameter to address multi service version routing.
|
If you rebase on master, I think that the CI should pass! |
|
I'm unfortunately not allowed to do so :( |
|
@m-guesnon-pvotal @a-manraj-pvotal |
7688aa2 to
c56898a
Compare
# Conflicts: # api/decision.go # api/decision_test.go # proxy/proxy.go # rule/matcher.go # rule/matcher_test.go # rule/repository_memory.go # rule/rule.go # rule/rule_test.go
|
This would be a great enhancement of Oathkeeper, is there any chance this will be picked up (or supported in a different way)? |
|
Hello @timdrijvers |
This pull request aims at extending the matching rules of ory oathkeeper with support for header matching.
Header-based routing pattern are a very common when in comes to versioned APIs. However, we should also consider that new versions of an API may result in a need for different authorization rules.
As such, support for header based decision making is relevant. We used to solve this issue with a proxy between our gateway and authService (oathkeeper) but figured it would be a welcome addition to oathkeeper rule definitions.
This change should NOT be a breaking change since defining headers in the rule is not required.
Related issue(s)
Documentation pull request can be found here
Related design document: ory/docs#820
Checklist
introduces a new feature.
contributing code guidelines.
vulnerability. If this pull request addresses a security. vulnerability, I
confirm that I got green light (please contact
security@ory.sh) from the maintainers to push
the changes.
works.
Further Comments
I'm not quite positive on which files in the repository are generated through your CI. Should I update the schema definitions?