https://github.com/tchoutri/acl
Haskell model of Zanzibar
https://github.com/tchoutri/acl
Last synced: about 1 year ago
JSON representation
Haskell model of Zanzibar
- Host: GitHub
- URL: https://github.com/tchoutri/acl
- Owner: tchoutri
- License: bsd-3-clause
- Created: 2025-04-10T14:53:37.000Z (about 1 year ago)
- Default Branch: main
- Last Pushed: 2025-04-29T13:07:12.000Z (about 1 year ago)
- Last Synced: 2025-04-29T13:44:45.877Z (about 1 year ago)
- Language: Haskell
- Size: 75.2 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 2
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE
Awesome Lists containing this project
README
# ACL
This package models an Access Control List (ACL) system with Google's [Zanzibar] as its main inspiration.
Examples are taken from Okta's [OpenFGA Sandbox].
## Terminology
ACL entries are three-tuples of an object, a relation and a subject (called subject in the Zanzibar paper).
A subject is the entity whose access of the object is being controlled. This is very close to how the grammar of some Western European languages work: subject, verb and object
The way to represent tuples is the following:
```
⟨tuple⟩ = ⟨object⟩#⟨relation⟩@⟨subject⟩
⟨object⟩ = ⟨namespace⟩:⟨object-id⟩
⟨subject⟩ = ⟨subject-id⟩ | ⟨subject-set⟩
⟨subject-set⟩ = ⟨object⟩#⟨relation⟩
```
Subjects can be directly identified by their subject identifier (`⟨subject-id`), or by a `⟨subject-set⟩`. From the Zanzibar paper:
> [⟨subject-set⟩] allows ACLs to refer to groups and thus supports representing nested group membership
### Examples
- 1. doc:readme#owner@user:10
- User 10 has the owner relationship to the readme object in the doc namespace
- 2. group:eng#member@user:11
- User 11 has the member relationship to the eng object in the group namespace
- 3. doc:readme#viewer@group:eng#member
- Members of group eng are viewers of doc:readme
## Relationships
### Direct relationships
The building block of an ACL is the declaration of a relationship between a subject and an object.
See Example 1.
### Computed relationships
In order to avoid storage waste, it is interesting to be able to specify transitive relations based on previously-declared relations.
For instance, an ACL modeling permissions on a document (reading, writing, admininistration) would benefit from
giving the writing permission to administrators, and reading permission to writers. This significantly reduces the number of tuples, as we go from:
```
doc:document1#admin@user:Théophile
doc:document1#writer@user:Théophile
doc:document1#reader@user:Théophile
doc:document1#writer@user:Léa
doc:document1#reader@user:Léa
doc:document1#reader@user:Nour
```
to
```
doc:document1#admin@user:Théophile
doc:document1#writer@user:Léa
doc:document1#reader@user:Nour
```
but the admin and writer retain their transitive permissions.
This kind of ACL check is resolved through the usage of a "rewrite rule" that expresses the inheritance of the "reader" relationship to the document by the "writer", and that of the "writer" by the "admin".
Expanding a rewrite rule provides more users in which to search for a permission match. Thus, the final set of users is not only `readers` but `readers ∪ writers ∪ admins`.
### Indirect Hierarchical Relationships
In order to further reduce the amount of tuples stored, and lower the maintenance burden, it is also interesting to grant permissions to other relations defined elsewhere.
For instance, the `reader` relation can be defined in terms of the membership to a group:
```
doc:document1#reader@group:guests#member
```
[Zanzibar]: https://storage.googleapis.com/gweb-research2023-media/pubtools/5068.pdf
[OpenFGA Sandbox]: https://play.fga.dev/sandbox/?store=entitlements