[HN Gopher] Why Authorization Is Hard
___________________________________________________________________
Why Authorization Is Hard
Author : samjs
Score : 123 points
Date : 2021-09-15 19:41 UTC (3 hours ago)
(HTM) web link (www.osohq.com)
(TXT) w3m dump (www.osohq.com)
| jzelinskie wrote:
| Disclaimer: I'm a founder of Authzed (YC W21), a productized form
| of Zanzibar
|
| I'd like to reiterate that Policy Engines and Zanzibar-like
| systems are orthogonal and can be used together very
| successfully. However, the article claims that ABAC cannot be
| done with ReBAC systems which is false[0] and it claims that
| Zanzibar systems do not support the concept of "public", when the
| system at Google does[1]. The availability of Zanzibar-like
| systems outside of Google is still relatively new, so the user
| experience can be greatly improved. For example, the Authzed
| Schema Language[2] is a vast improvement over Zanzibar's raw
| userset rewrites.
|
| That being said, I think the Oso UX is quite nice in comparison
| to many products in the space, but architects should always spend
| the time to figure out what's best for their requirements. If
| you're just starting to explore AuthZ, this article is a pretty
| good primer for the problems in the space and why you're unlikely
| to design something great on the first go if you build it
| yourself. It's really hard to write about this subject in a
| digestible fashion, so props to the team!
|
| I especially liked the quote "[...] authorization is a topic as
| cool as moving to Kubernetes!". Considering almost all of our
| team is ex-CoreOS and has deep ties to Kubernetes, we truly
| believe authorization is cool enough to stop working on
| Kubernetes ;)
|
| [0]:
| https://link.springer.com/chapter/10.1007/978-3-662-43936-4_...
|
| [1]: https://www.youtube.com/watch?v=mstZT431AeQ
|
| [2]: https://play.authzed.com
| [deleted]
| samjs wrote:
| Hey! Yep, you can totally use a policy engine like XACML or OPA
| with Zanzibar. We talk about that a little further down in the
| post.
|
| The "public" example was meant to be a simple example of
| attribute-based access control but you could replace that with
| other similar ABAC examples for why you might need to bring in
| an additional policy engine.
| stevenpetryk wrote:
| I've never used it in prod, but have heard great things from
| former Intercom coworkers about how easy it was to rewrite the
| whole auth layer in Oso. Never heard someone describe being
| "blown away" building an auth layer but here we are.
|
| Congrats to the Oso team for building a great product :)
| samjs wrote:
| Thanks! I'll pass it on to the team :D
|
| I've got to say, the folks at Intercom made it particularly
| fun. They were sending us traces and graphs from their internal
| systems when we trying to figure out some issues with them
| (e.g. we ran into this datadog context problem:
| https://github.com/DataDog/dd-trace-rb/issues/1389)
| ianstormtaylor wrote:
| Wow, it's really refreshing to see authorization explained in a
| way that dives into the fine details. Most articles I've seen
| introduce global role-based restrictions and leave it at that
| which is super frustrating.
|
| Oso looks really well considered. Wish I had this in the past.
| Well done!
| samjs wrote:
| Thank you! You might also enjoy the series we've been writing,
| Authorization Academy:
| https://www.osohq.com/developers/authorization-academy
|
| It builds up a bit more gently and introduces a lot more
| concepts than I could fit into one (already long) blog post.
| titive wrote:
| Wish we had this when we just spent 4 months building this 3
| separate times across 3 separate products.
| rad_gruchalski wrote:
| What did you end up using?
| brabel wrote:
| Seems to be an alternative to OPA:
| https://www.openpolicyagent.org/
| xtracto wrote:
| From my limited research looking for authorization systems [1]
| it is but it is not: OPA can get actually quite slow for "real
| world" production scenarios. For example until recently Ory
| Keto used OPA and had that issue https://github.com/open-
| policy-agent/opa/issues/1443 . It seems to me that Oso although
| is based in Opa and Zanzibar ideas, it may have some
| performance improvements and ease of use.
|
| [1] (we are planning to change a half-assed internal auth
| system to a pre-existing one)
| xcskier56 wrote:
| Question if anyone from the Oso team is here: From what I've
| read, the Oso core is built in rust, but then is it called from
| Ruby or is it re-implemented in Ruby? I couldn't see any native
| extension like code in the ruby portion of the repo but could
| easily have missed it.
| hobofan wrote:
| It is a wrapper around the Rust code:
|
| - It triggers the rust build in the Makefile:
| https://github.com/osohq/oso/blob/1d3bf5a4a997a574c2b19084a0...
|
| - There is a bunch of FFI code (also in the ffi directory):
| https://github.com/osohq/oso/blob/1d3bf5a4a997a574c2b19084a0...
| gkaemmer wrote:
| Hey, Oso engineer here. Good question.
|
| The rust core is indeed called from the ruby library (as it is
| with all of our 5 other host libraries). The core itself is
| pretty complex (there's a whole parser/interpreter in there),
| so maintaining it in a bunch of languages would be a bit
| hectic.
|
| There are some files inside `lib/oso/polar/ffi` that define the
| C bindings used by the rest of the library. Here's an example:
| https://github.com/osohq/oso/blob/main/languages/ruby/lib/os...
|
| We use the ffi gem to make that work:
| https://github.com/ffi/ffi
|
| EDIT: hobofan beat me to it! :)
___________________________________________________________________
(page generated 2021-09-15 23:00 UTC)