Earlier quoted context omitted.
I love that this _doesn't_ have a persistence layer. Authorization _should_ be just a library
You need to store the policy somewhere.
Okay but that’s a separate concern
Gatehouse – a composable, async-friendly authorization policy framework in Rust
21–29 of 29 posts
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#22command-f "license" :-( I do see https://github.com/thepartly/gatehouse/blob/v0.1.2/Cargo.tom... > but my experience with package manager license declaration is that it is almost always "yeah, yeah, default, whatever" versus an explicit choice. They are also invisible to the GitHub license widget, which places the burden upon the user to go spelunking around in the code to know for sure
I did put licence = "Apache-2.0" in the Cargo.toml but Partly is okay with it being MIT. Update the repo to explicitly add the license text now. Thanks for the call out
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#23Very 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.
Thanks! I'm a big fan of Cedar and DSLs such as CEL and gorules. Hopefully there is a place for a Rust solution as well.
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#24What's the persistence layer?
BYO persistence
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#25Is 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?
Nah, I think your intuition is correct it should be broken up.
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#26Earlier quoted context omitted.
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.
Yeah it makes more sense now. First I was looking at the Axum integration example https://github.com/thepartly/gatehouse/blob/a3b46bcb37353cb5... where they do the simulated I/O first and then do a policy check that consists only of business logic without any I/O as far as I could tell https://github.com/thepartly/gatehouse/blob/a3b46bcb37353cb5... Because there from what I could see, all decisions made by the polici…
You're spot on - we wanted to support some async graph traversal calls similar to the ReBAC example and therefore made the evaluate_access call async. I also wanted to support short circuiting such that somewhat expensive IO calls might be skipped by returning early from a policy that didn't need to make that call.
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#27This 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 colo…
Agreed! But you're glossing over the Zanzibar point of view on this topic, which falls back to dual-writes. That approach has a lot of downsides: "Unfortunately, when making writes to multiple systems, there are no easy answers."[0] Having spoken with the actual creators of Zanzibar, they lament the massive challenge this design presents and the heroics they undertook over 7+ years at Google to overcome them. By cont…
Yeah a big motivation for us was avoiding the need to keep another system up to date. Gatehouse basically sits at the execute policy layer, and we let the application code decide how to unify the data (or not).
Oso local authorization looks like a fantastic solution.
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#28This 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 colo…
Agreed! But you're glossing over the Zanzibar point of view on this topic, which falls back to dual-writes. That approach has a lot of downsides: "Unfortunately, when making writes to multiple systems, there are no easy answers."[0] Having spoken with the actual creators of Zanzibar, they lament the massive challenge this design presents and the heroics they undertook over 7+ years at Google to overcome them. By cont…
Thanks for the response. In my opinion, oso does the best of job of any policy engine at prescribing how input data to their system is fed (and your linked blog demonstrates it well!).
I do think you might have pivoted the conversation, though. My post was purely about federation strategies and policy engines, but you appear to discussing consistency and Zanzibar, which is only tangentially related. Federation and consistency aren't necessarily coupled. Oso also would require a complex scheme for achieving strict serializability, but it instead chooses to trade-off consistency of the centralized data in favor for the local data.
Re: Gatehouse – a composable, async-friendly authorization policy framework in Rust
#29Earlier quoted context omitted.
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.
In general, a problem with big files is encapsulation -- ideally you want private fields to have as little visibility to other code as possible.
Agreed but this really depends on what tools the language gives you for modules. Some languages have the module structure directly coupled to the file layout like JavaScript, where others are a lot more flexible.