Permissions examples

In order to better understand how the Kinto permission model works, it is possible to refer to this set of examples:

Example	Description
Blog	Everyone can read; Authors can write / read / create articles
Wiki	Authenticated users can write / read / create; Everyone can read.
Company Wiki	Employees can write / read /create anything; Managers can add employees
Microblogging	A micro blogging platform like twitter

A Blog

Consider a blog where:

• A list of administrators can CRUD everything;
• Some moderators can create articles and update existing ones;
• Anybody can read.

The following objects are created:

• A bucket servicedenuages_blog;
• A collection articles;
• A group moderators with members fxa:<remy id> and fxa:<tarek id>.

Object	Permissions	Principals
Bucket servicedenuages_blog	write	fxaoauth:<alexis id> fxaoauth:<mathieu id>
Collection article	write	/bucket/servicedenuages_blog/groups/moderators
	read	system.Everyone

A Wiki

• Authenticated users can create, retrieve, update and delete anything;
• Everyone can read articles.

The following objects are created:

• A wiki bucket, where new groups can be created by authenticated users;
• An article collection is created.

Object	Permissions	Principals
Bucket wiki	write	fxa:<wiki administrator id>
Collection articles	write	system.Authenticated
	read	system.Everyone

A Company Wiki

• Employees of the company can CRUD anything;
• Managers can add employees to the wiki;
• Other people don’t have access.

The following objects are created:

• A companywiki bucket;
• An articles collection;
• An employees group.

Object	Permissions	Principals
Bucket companywiki	write	fxa:<wiki administrator id>
Group employees	write	/buckets/companywiki/groups/managers
Collection articles	write	/buckets/companywiki/groups/employees /buckets/companywiki/groups/managers

A microblogging

A microblog is a service to share short articles with people such as Twitter, Google+ or Facebook.

• The microblog administrator creates the bucket;
• Each collection is isolated from the others, and only one person have all permissions on all records;
• Records are private by default, and published to specific audiences.

The following objects are created:

• A microblog bucket, where groups can be created by authenticated users;
• A single article collection;
• A group alexis_buddies, whose members are chosen by Alexis (a.k.a circle);
• Some records (messages) with specific visibility (public, direct message, private for a group)

Object	Permissions	Principals
Bucket microblog	write	fxa:<microblog administrator id>
	group:create	system.Authenticated
Collection articles	record:create	system.Authenticated
Group alexis_buddies	write	fxa:<alexis id>
A public message	write	fxa:<alexis id>
	read	system.Everyone
A direct message for a user	write	fxa:<alexis id>
	read	fxa:<tarek id>
A private message for a group	write	fxa:<alexis id>
	read	/buckets/microblog/groups/alexis_following

Each time a user creates a new record, it needs to setup the ACLs attached to it.

With this model it is also possible to setup a shared microblogging account giving record’s write permission to a group of users.

Note

Another model could be to let users create their own collections of records.

Mozilla Payments tracking

For the payment tracking use case, three players are involved:

• The payment app, storing receipts for buyers and sellers;
• The selling app, reading receipts for a given seller;
• The buyer app reading receipts for a given buyer.

Users shouldn’t be able to write receipts themselves, sellers and users should only be able to read their owns.

The following objects are created:

• the mozilla bucket;
• the payment collection.

Object	Permissions	Principals
Bucket payments	write	hawk:<payment app>
On every record	read	hawk:<selling app> fxa:<buyer id>

This ensures every app can list the receipts of every buyer, and that each buyer can also list their receipts. However, only the payment application can create / edit new ones.