Gatehouse – a composable, async-friendly authorization policy framework in Rust
1–10 of 29 posts
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#2async-friendly Rust native library with decision traceability.
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#3What's the persistence layer?
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#4What is the advantage of having the policy checking be an async function? From a brief look (framework itself and one of the examples provided in the examples directory) it seems that you’d typically be doing all I/O operations up front before invoking the policy checker, and that doing the policy check does not itself involve any I/O.
I only looked over the code quickly so I’m probably overlooking something.
It would be neat to get the motivation for each of the functions that are async being async instead of just “normal” functions.
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#5What is the advantage of having the policy checking be an async function? From a brief look (framework itself and one of the examples provided in the examples directory) it seems that you’d typically be doing all I/O operations up front before invoking the policy checker, and that doing the policy check does not itself involve any I/O. I only looked over the code quickly so I’m probably overlooking something. It woul…
The examples just don't show any I/O but you could easily imagine that the actual policy check is done by a different service which lives across an I/O boundary or involves DB lookups to validate if the action on the given resource by the subject within the given context is allowed.
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#6Very cool project. I’ve used the cedar crate for similar use cases in the past but it’s always bugged me that it requires writing the policies in yet another language.
Will definitely check this out.
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#7Is it standard to have 2k+ loc in a lib.rs file? I'm looking at Rust code and it seems that everything goes in there. People usually don't break that down?
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#8This project looks like a very nice lightweight way to implement policy in a Rust application; I really like the ergonomics of the builder. Despite being very different systems, the core permissions check being the same signature as a call to SpiceDB[0] (e.g. the subject, action, resource, and context) shows the beauty of the authorization problem-domain regardless of the implementation.
I would like to add some color that a policy engine is not all you need to implement authorization for your applications. Without data, there's nothing for a policy engine to execute a policy against and not all data is going to be conveniently in the request context to pass along. I'd like to see more policy engines take stances on how their users should get that data to their applications to improve the DX. Without doing so, you get the OPA[1] ecosystem where there are bunch of implementations filling the gap as an afterthought, which is great, but doesn't give a first-class experience.
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#9Very cool project. I’ve used the cedar crate for similar use cases in the past but it’s always bugged me that it requires writing the policies in yet another language. Will definitely check this out.
A separate policy language is explicitly useful for those that want to be able to reuse policies in programs written in different languages. It's a part of the best practice (for larger orgs/products) for decoupling authorization logic and data from your application codebases.
When you're just hacking something together, you're totally right, it might as well be Rust!
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#10Is it standard to have 2k+ loc in a lib.rs file? I'm looking at Rust code and it seems that everything goes in there. People usually don't break that down?
I used to think big files were a problem but I've come to like them more as the years go by. I don't have to wrap my head around some organization scheme which might be half baked - it's all right there.