gkaemmer

Airbnb Himeji: https://medium.com/airbnb-engineering/himeji-a-scalable-cent... Carta's AuthZ system: https://medium.com/building-carta/authz-cartas-highly-scalab... Slack's architecture is a bit different, but solves some of the same challenges: https://slack.engineering/role-management-at-slack/

I've also talked to a number of teams who just implemented pattern 3 internally with a custom service. Generally they've determined it's worth it to centralize all authorization data (like roles, groups, etc) into one place and perform ALL permission checks there.

There are also some companies building essentially Zanzibar clones, like Auth0, Authzed, Ory Keto, and a few more.

Like pphysch said, using RBAC generally gets you 90% or more of the way there on this, and a good intro to this concept is the Tailscale post: https://tailscale.com/blog/rbac-like-it-was-meant-to-be/

In most cases (even with many 100s of thousands or millions of users), there are far fewer _roles_. So you can generally answer the question of "which users can access this resource" by answering the questions "which roles can access this resource", and "which users have those roles". If you're using SQL to store roles and role assignments, your query for all users becomes:

    select * from users
    join user_roles on user_roles.user_id = users.id
    where user_roles.role_id in [... small list ...]

All that being said, I think there's definitely more to be written here. Keep a lookout -- we might do some more writing about the topic.

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! :)