Zephyr - Elixir authorization system based on the ReBAC model inspired by Google's Zanzibar

Hello, everyone!

I’m thrilled to introduce Zephyr, an open-source authorization library for Elixir that leverages the power of Relationship-based Access Control (ReBAC). Zephyr is inspired by Google’s Zanzibar and closely follows the syntax of Authzed’s SpiceDB.

How does it work?

The concept of ReBAC circles around the subject and its relation to an object. For example,
User Alice is the creator of Issue Typo. In this statement, User Alice is the subject, Issue Typo is the object, and the relation of Alice to Typo is “creator”.

We can save this relation via:

Zephyr.write!({"users", "Alice", nil}, {"issues", "Typo", "creator"})

We name user Alice and issue Typo for the sake of discussion only, but in the real world they should be unique identifiers like integer or uuid

With that said, we can define their relationship as something like:

definition :users

definition :issues do
  relation(:creator, :users)
end

By extending the definition above, we can also say that creators can also close the issue:

definition :users

definition :issues do
  relation(:creator, :users)
  relation(:closer, :creator)
end

With this, we can then check that Alice is a creator and also a closer

iex> Zephyr.check(issue, "creator", alice)
true

iex> Zephyr.check(issue, "closer", alice)
true

The issue and alice here are ecto schema with id and table metadata.

We can also relate an object to another object. For example, a statement saying Maintainers of Repository Zed that is a parent of Issue Typo can also close the issue:

definition :users

definition :repositories do
  relation(:maintainer, :users)
end

definition :issues do
  relation(:creator, :users)
  relation(:parent_repository, :repositories)
  relation(:closer, :creator + (:parent_repository > :maintainer))
end

Let’s try to save a maintainer relation to a parent repository and also a parent repository relation to the issue, respectively:

Zephyr.write!({"users", "Bob", nil}, {"repositories", "Zed", "maintainer"})
Zephyr.write!({"repositories", "Zed", nil}, {"issues", "Typo", "parent_repository"})

Now we can check that Bob can also close Issue Typo:

iex> Zephyr.check(issue, "closer", bob)
true

Key Features:

  • ReBAC Authorization: Zephyr allows you to define and enforce complex access control policies based on the relationships between users and objects in your application.
  • Inspired by Zanzibar and SpiceDB: While rooted in the concepts of Google’s Zanzibar, Zephyr closely follows the semantics of SpiceDB, making it familiar to those who have used these systems.
  • Powerful Operators: Zephyr supports union, exclusion, intersection, and walk operators for creating nuanced access control policies.

Caveat (Important!!)

This library is still in its alpha version there is still more work to do like the extend API in addition to write and check, more fixes, and of course documentation.

Feedback and Contributions:

I’d love to hear your thoughts on Zephyr. Contributions, whether they be bug reports, feature requests, or code, are always welcome. Let’s work together to make Zephyr a powerful tool for the Elixir community!

17 Likes

@dgigafox this is a fantastic addition to the Elixir ecosystem! I was about to start using SpiceDB and will give this a try. I’m trying to use Elixir for as much as I can to streamline things because I’m one person working on a project. I love the vision of this library and am excited to see where it goes.

For those that don’t know about Zanzibar or SpiceDB I recommend checking it out. This approach is a great fit for apps with complex authorization needs and we needed something like this.

The malach-it/boruta-server project by @pknoth would pair nicely with this to offer an all-elixir solution to auth, identity management, and resource management.

Thanks @wtcross! It’s still a work in progress, honestly the foundation is still buggy but the idea is there. Planning to release a much stable version soon!

Woah, I missed your first post but this is fantastic :face_holding_back_tears:

A few questions:

  • I remember reading whitepapers, and they were talks about performance, especially when you’re traversing the relation graph. How does Zephyr solve that? How entries are loaded recursively in the DB in case of > relation?
  • How about using Elixir keywords for Zephyr’s DSL? Like :creator or (:parent_repository -> :reader) instead of :creator + (:parent_repository > :reader)? What are the pluses and minuses?
1 Like

Thanks @tangui

  • The relation graph is just a simple recursion for now but currently on the works of using libgraph or any other graph structure libraries. On the db side I use recursive compile-time expressions, planning to have adapters in the future so we can compare which storage works best. To be honest I am not yet concerned with the optimization as I want to make it work first with different patterns presented in spicedb

  • We could do that as long as it is not in the Kernel.SpecialForms. Right now I followed spiceDB’s operators where pluses are unions (similar to or) and minuses are exclusions.

1 Like