I find that the most difficult part of using Ory i...
# talk-oathkeeperh
helpful-keyboard-62948
11/01/2022, 7:39 PMI find that the most difficult part of using Ory in our stack is managing access rules. Not being able to handle overlapping URL matches with a priority system of some kind makes rule management a huge pain.
Is there a best-practices guide to managing complex routes with Oathkeeper? Am I really stuck explicitly mapping out every single rule for every URL if they share some base level path that's hard to describe with regex?
helpful-keyboard-62948
11/01/2022, 7:42 PMDefinitely struck by the difficulty of this because I feel my only real options here are:
A) Explicitly write dozens and dozens of rules that will become difficult to maintain
B) Use very complex regex, still write a ton of rules, and accept that eventually someone within our engineering team will make a typo that exposes secrets to the world.
helpful-keyboard-62948
11/01/2022, 7:45 PMThe hassle of not being able to handle overlapping matches is really exacerbated by the sheer amount of boilerplate required to define a rule.
An app framework can describe an application's routes in a dozen lines that equates to hundreds of lines of configuration as Oathkeeper rules.
f
faint-helmet-53309
11/01/2022, 10:03 PMTo be fair, I think you can use YAML anchors to reduce boilerplate. But I agree, overlapping matches would be very useful.
r
red-machine-69654
11/02/2022, 9:51 AMI also want to second yaml, writing them in json is so painful, and at least the yaml let's you comment đ
red-machine-69654
11/02/2022, 9:52 AM@helpful-keyboard-62948 I generally use the glob pattern, can you give an example of how rules overlap or what you are facing specifically?
red-machine-69654
11/02/2022, 9:52 AMglob as in,
<https://example.org/{/,/foo>, /foo/**}f
fresh-byte-82421
11/02/2022, 1:52 PMI feel in terms of best practices it's recommended to use a dedicated api gateway/router/load balancer to direct your ingress traffic to the oathkeeper port of your backend services for authn and authz. That way oathkeeper only has to worry about the routes of your specific service as opposed to the global routing of your entire application.
In my case I have three different access rules for my various routes:
⢠noop (for static assets such as css files or images)
⢠anonymous (things that may, but do not require an active session)
⢠bearer token (things that require an active session)
e.g. simple frontend and backend api see above
fresh-byte-82421
11/02/2022, 1:53 PMas you can see the exclusion of the routes makes the syntax a little awkward (<(?!\/static|\/api).+>), but as for now I feel its manageable in my case to use prefix routes for access rules (e.g. /api/+, /static/+, /public/+) and strip those when forwarding the request
r
red-machine-69654
11/02/2022, 2:07 PMSo you want /static and ânot staticâ
red-machine-69654
11/02/2022, 2:07 PMI see
red-machine-69654
11/02/2022, 2:08 PMYeah, I loath regex, we basically use globs and are more explicit to avoid that
red-machine-69654
11/02/2022, 2:10 PMMaybe the decision api and forward-auth/external auth is better for you? Then you wouldnât run oathkeeper as a reverse proxy
h
helpful-keyboard-62948
11/03/2022, 5:11 AMWe're currently using Oathkeeper as the middleman between the user and an array of APIs in our Kubernetes cluster, all of whom provide both public endpoints and authenticated endpoints with more specific permissions.
Given what we actually want Oathkeeper to do: allow unauthenticated access to some endpoints, require a valid cookie for others... the implementation is a bit painful given how simple the ask is.
Even the simplest usecase of assuming we want cookie authentication by default and explicitly whitelisting public URLs seems to be currently impossible without the ability to define overlapping rules.
2 Views