Allow multiple rules for one URL

[wawan93]

If URL matches by multiple rules, Oathkeeper returns 500 error Expected exactly one rule but found multiple rules. I think, this is bad idea.
For example, if we want to add two rules: /<.*> with token introspection and /swagger.json without introspection.
Now we can't just add this 2 rules. This enforces us to create many rules for every /* route to avoid overlap.
This error is not obvious. It will appear only in runtime, Oathkeeper don't test it during rules import.
This is not internal, not server, and not exactly error - so, returning 500 error is wrong

My proposal is to add priority field to rule definition, and to apply rule with the highest priority for given URL.

Alternative solutions:

1. Use PCRE instead of default golang's RE2 to allow using negative lookahead in rules definition
2. Add exclude_url field in match
3. Just don't return 500 and apply first matched rule

[aeneasr]

Is there a good library for negative lookahead in Go? I generally agree that there should be some way to have <.+> while also being able to exclude some paths. The 500 error still makes sense because what we want to avoid is that something accidentally is allowed although a rule denied it. Precedence with priority is usually not a good idea in security contexts because it's very easy to lose track of what's happening.

We could probably also add something like oathkeeper rules test ... which would run some tests (e.g. with credentials or whatever) against a set of rules. This would be very equal to just running a bunch of curls.

We can obviously not detect rule conflicts automatically on start up because we would have to brute force URLs against your rules which is not practical.

[wawan93]

I've already lose track of what's happening. That's why I got this error and that's why I propose this. For me, priority field is way more obvious, than complicated regexps or plenty files with rules for every route.

[aeneasr]

I disagree on priority. Priorities for security sensitive rules can lead to serious security issues. It's better to disallow stuff explicitly.

What we could obviously do is to support more than regex matching and have stuff like glob matching which is also a bit easier to use and also supports negative lookahead (I think): https://github.com/gobwas/glob

[aeneasr]

Closing in favor of #167

[stszap]

We encountered exactly the same problem today. As a temporary hack I used this pattern (edited) for swagger https://example.com/api/v1/swagger.json and this for the actual api endpoints https://example.com/api/v1/<[\\w\\-\\/]+>. It works in our case because none of the endpoints has "." symbol. Hope it helps somebody.

[aeneasr]

Thank you for pointing that out - it is certainly helpful as a workaround until #167 lands!

[nitedani]

I can't figure out how to make this work.

I have 2 upstream services.
I want /auth/** to proxy to service A (kratos-ui).
I want everything else to be proxied to service B.

How is #167 helping with this?

[llbarbosas]

I can't figure out how to make this work.

I have 2 upstream services.
I want /auth/** to proxy to service A (kratos-ui).
I want everything else to be proxied to service B.

Any updates?