Hey guys, First off, I’ve just found ory and took...
# talk-oathkeeper
s
Hey guys, First off, I’ve just found ory and took me a few mins to get setup and running - what an awesome dev experience coming from hacking away at AWS cognito or custom built systems. Really enjoying it! I’d like to use oathkeeper but have 2 questions around the access control plane which I raised here https://github.com/ory/oathkeeper/discussions/944 . 1. What’s the ability to use the zanzibar / keto authorizor when you are using a binary protocol for fine grained permission checks? E.g. trying to read an item and the item ID you want to pass to keto for a check is embedded into the binary protobuf as a field? You would need to decode the protobuf message and then access the ID? 2. What’s the ability to use this for long-lived / stateful connections like websocket messages or grpc streaming? (e.g. client streaming messages, could we use oathkeeper at more of an application level to intercept messages, authz check them like in step 1 and proceed or respond) 3. Bonus question: could you run oathkeeper on outbound responses? E.g. on inbound we’ve validated that you’re allowed to try access this resource but in a true “zero trust” can we validate that the service is allowed to respond with that content to the consumer?
m
Thanks for the feedback Daniel! Interesting questions! I will see if I can get a good answer on the GitHub discussion.
s
I had another one which was more of a feature suggestion 😂 My understanding of zero-trust is not too great and it feels a bit buzzwordy so I may be using it out of context here but: For true “zero trust” should we also push the service responses through oath keeper and provide response filtering? I.e. we’re currently validating is the current request allowed to access this resource. Should we also consider validating is the current resource allowed to respond with that content? e.g. search or list queries are quite dynamic in nature…. dont want some item that doesn’t belong to the user to be in there… or reading a user resource is fine, but we’re returning some highly secure field in the response which shouldnt be there