Access through relationships

Owners, members, and sharing

None of those facts is a role in the usual sense. Nobody picked Owner from a list of roles for Maya. Ownership connects Maya to this one album, recorded when the album was opened, and the next album will have its own owner. None of them is a fixed attribute either. Lena's access is not a property of Lena, like a desk, or of the album, like a license region. It is a connection between Lena and album 4410 in particular, and it exists because someone made it. Facts like these are relationships, and deciding access by following them is called relationship-based access control, or ReBAC.

You have met this model before. The friend who shared a photo album in Deciding what someone can do created a relationship between you and that album, and changing album 42 to 43 failed because no such relationship existed for album 43.

The other models have not gone anywhere, and the boundaries between them are softer than their names suggest. A scoped role assignment is already close to a relationship: Omar's group holds Picture editor in the Sports library, a fact that connects a group, a role and one place. Lena's Contributor assignment on album 4410, from Roles, assignments, and scope, is the same fact as the contributor relationship below, written another way. Attributes still add conditions that relationships cannot express. Omar can edit every photo in the album through the library, yet once Raj places a legal hold on photo 9001, the hold rule still stops Omar from deleting it. Many systems use all three: relationships say who is connected to what, roles name what a connection allows, and attributes add the conditions.

Relationships as data

A system built on relationships stores each one as a small fact with three parts: an object, a relation, and a subject. One common way to write them puts all three on a single line:

album:4410#owner@user:maya
album:4410#contributor@user:lena
group:sports-desk-editors#member@user:omar
library:sports#editor@group:sports-desk-editors#member
album:4410#parent@library:sports
photo:9001#parent@album:4410

Read album:4410#contributor@user:lena from left to right: on the object album 4410, the relation contributor is held by the subject user lena. The type before each colon keeps identifiers from colliding, so album 4410 can never be confused with a photo that happens to share its number. This notation is one convention among several, used here for illustration. What matters is the three parts.

Two kinds of line need a closer look. In the fourth, the subject is not a single person but group:sports-desk-editors#member, meaning everyone who is a member of that group. Adding a picture editor to the group makes them an editor of the Sports library without touching any of the library's facts. The last two lines record containment rather than access: photo 9001's parent is album 4410, and the album's parent is the Sports library. The diagram below draws both as "in".

The facts are only half of the model. The other half is a short set of rules about what each relation means, written once for each type of object rather than once for each album:

• An album's owner is also an editor of it, an editor is also a contributor, and a contributor is also a viewer.
• Whoever holds one of these relations on a library holds the same relation on every album in it, and whoever holds one on an album holds it on every photo in that album.
• Each permission needs a relation: photo.view needs viewer, photo.upload and photo.edit_caption need contributor, and photo.delete needs editor.

These rules keep the stored facts few. Nobody writes a separate fact saying that Maya can view photo 9001, or that Omar can delete it. Both follow from the facts and the rules together.

Following the graph

Together, the facts form a graph. People, groups, libraries, albums and photos are its points, and each fact is a line between two of them. Deciding a request becomes a search for a path.

Take "can Lena view photo 9001?" first. Viewing a photo needs the viewer relation. No fact on photo 9001 names Lena, so the search follows the photo's parent to album 4410 and asks whether Lena is a viewer there. The second fact makes Lena a contributor, a contributor is also a viewer, and the answer is yes. The path is short: photo, album, Lena.

"Can Omar delete photo 9001?" takes longer. Deleting needs the editor relation. Nothing on the photo names Omar, so the search moves up to album 4410. Omar is neither its owner nor one of its editors, so the search follows the album's parent to the Sports library. The library's editors are the members of Sports desk editors, and Omar is a member. The path runs photo, album, library, group, Omar, and the answer is yes.

A search that finds no path ends in a refusal. When Lena asks to delete photo 9001, the search finds Lena as a contributor to the album, but contributor does not imply editor, and no other path leads from the photo to Lena with the editor relation. The answer is no. Access exists only where a path proves it, which is default deny in another form. Maya, meanwhile, holds every relation on the photo through a single ownership fact on the album, because the rules make an owner an editor, an editor a contributor and a contributor a viewer.

The path is also the explanation. Asked why Omar can delete photo 9001, the system can show the chain of facts that granted it, and removing any one of them, such as Omar's membership in the group, removes the access. That is a clearer answer than rules over attributes can usually give.

Asking the reverse question

The library's home page asks a different question. When Lena opens it, the page needs every photo Lena can see, not a yes or no for one photo. A check starts with two known points and looks for one path between them. A list starts from Lena alone and has to follow every path outward: every album shared with Lena directly, every group Lena belongs to and everything those groups can see, every library those reach, every album in those libraries, and every photo in those albums.

For Lena the answer is small: one album and its photos. For Omar it covers the whole Sports library and the News library, where Omar holds Viewer, and together they may hold hundreds of thousands of photos. A search results page needs the first fifty of those that match a keyword, sorted by date. Checking every photo in both libraries one at a time would take far too long.

This is why systems built on relationships index them carefully. They keep the facts searchable in both directions, from an object to its subjects and from a subject to its objects. Many also keep precomputed answers for the expensive parts, such as each person's full list of groups once nesting is expanded, or the libraries and albums each group can reach, and update them as facts change. A search can then filter photos by the containers a person reaches instead of checking photos one by one. List pages and search are where these systems work hardest, and where an index that falls behind the facts can show someone a photo they are no longer allowed to see. Keeping checks and indexes in step with changes is part of Sharing and revoking access.