Some use cases

Payments

For the payment use case we have three players involved:

• The payment app that stores payments for users
• The selling app that can read records of the given app
• The user that can read its records

A record would be stored like that:

{"shared_principals": ["user:me", "app:sellingapp"],
 "year": 2015, ...}

The collection would be /buckets/concrete/collections/payments

Permissions on the collection would be:

{
  "scope:payments": ["read_shared_records"],
  "scope:sellingapp": ["read_shared_records"],
  "scope:paymentapp": ["ALL"]
}

Then,

• the sellingapp can GET /buckets/concrete/collections/payments/records and will get back all records that are shared with it.
• the user using the payments scope can GET /buckets/concrete/collections/payments/records and will get back all records that are shared with her.
• the paymentapp can access /buckets/concrete/collections/payments/records and will have all the records.

Blog

We can also give them ALL access to the blog collection:

PATCH /buckets/servicedenuages/collections/blog

{
  "permissions": {
    "user:[email protected]": ["+ALL"]
  }
}

Twitter

Collection is isolated, CRUD your own records and ready everyones tweets.

The CRUD only if by default because natim is owner of the natim bucket.

We can add the Everyone read_all_records permissions:

PATCH /buckets/natim/collections/tweets

{
  "permissions": {
    "Everyone": ["+read_all_records"]
  }
}

Do we want something like: GET /buckets/*/collections/tweets to read all shared buckets? I am not quite sure about it.

Wiki

PATCH /buckets/natim/collections/wiki

{
  "permissions": {
    "Everyone": ["read_all_records", "update_all_records", "delete_all_records", "create_records"]
  }
}

Company Private Wiki

PATCH /buckets/company/collections/wiki

{
  "permissions": {
    "bucket:company": ["ALL"]
  }
}

from kinto.

Wow, this issue tries to cover a lot of different things at once (introducing the bucket concept and defining the exposed APIs for permissions)!

Buckets

I do agree that permissions introduce a big shift in how we currently expose our APIs, and I think I like the bucket approach.

However:

It also means that collection doesn't necessarily belongs to one user only but can have multiple owners.

It's entirely possible to have the collection belong to one user and have this collection accessible by many different users. It is similar to what github proposes with their repositories: it's mine by I can have others publish information there, even without my consent.

To continue the github comparison, buckets seems a lot like what they called "organisations". I like the fact to let the meaning open, because as you said "The benefit from having bucket is that we let the user defines what does the bucket means".

Permissions

I concur with the fact we should continue using the +, -, All and Authenticated concepts we had in Daybed (back in the old times!).

I think we should define a formalism for all the objects and associated permissions matrixs. For instance, I would say we reuse the objects and permissions defined in #33 and have something like {object}_{permission} for all the combinations.

There is still a bunch of shadow spost I would like to get adressed:

I don't understand what is the concept of "shared_principals" you introduced, and I believe we don't need to have the concept of sharing exposed at all in our APIs.

And it's actually where it starts to get complicated. Let me use an example to explain what I feel is painful and what needs resolving here.

Imagine you have a collection where you want to share specific records with specific people. For instance, Rémy has a blog where posts about "music" can be edited by "musicians" and posts about "bike" by "bikers".

For each record, it's possible to push the associated permissions. If Rémy wants "Severine" and "Alexis" to edit posts about music, then he needs to add them to all the records that are talking about music to add them to the permissions.

(I'm aware of the limitatons of this example — it's possible to create a collection per category — but I hope you can grasp my concerns out of it)

Having a concept of "groups" would help solving this, and maybe that's what you tried to bring with the "shared_principals"? If so it seems it's not fine grained enough to cover this use case.

Also, we need to be aware that's something we tried to solve with daybed in our first iteration and had something way more complex that what we wanted as a result.

from kinto.

I don't understand what is the concept of "shared_principals" you introduced, and I believe we don't need to have the concept of sharing exposed at all in our APIs.

The name is maybe not the right one, but it is the list of principals having access to the record using the collection read_shared_records permissions.

from kinto.

For each record, it's possible to push the associated permissions. If Rémy wants "Severine" and "Alexis" to edit posts about music, then he needs to add them to all the records that are talking about music to add them to the permissions.

Yes I agree about the group concept, we can add a new category of principals for it.

What I had in mind was to create a bucket musicians with Alexis and Severine in it and add the bucket:musicians to all the records that need it.

from kinto.

The name is maybe not the right one, but it is the list of principals having access to the record using the collection read_shared_records permissions.

Here, "access" is not defined enough. What does that mean? Which permissions?

from kinto.

Here, "access" is not defined enough. What does that mean? Which permissions?

It depends of the permissions you've put on the collection containing the record.

If you've got {'bucket:musicians': ["read_shared_records", "update_shared_records"]} and on the record {"shared_princiapls": ["bucket:musicians"]} then it means having read and update access but not deletion.

from kinto.

Yes I agree about the group concept, we can add a new category of principals for it.

Interesting, I like that. Then it means that users can obtain different principals depending on which collection they're acting (because musicians means something different for me and for other users).

from kinto.

Then it means that users can obtain different principals depending on which collection they're acting

I was thinking having group accross all users and collections but I remember we had policies, in Daybed before, letting us do per collections groups.

Maybe what we need is bucket's groups as does github with Organization teams.

from kinto.

Sorry, I find this API proposal cryptic. "shared" should reflect a state and records don't have a "shared: true/false" attribute.

Oh, I think I got something interesting!

Rather than defining the relation with "principal →list of permissions" we could do it backwards "permissions → list of principals".

Old:

{'bucket:musicians': ["read_shared_records", "update_shared_records"]}

New:

{
  'read_record': ["group:musicians"],
  'update_record': ["group:musicians"]
}

Where groups would be defined inside the collection; or if not there, on the bucket.

from kinto.

Rather than defining the relation with "principal →list of permissions" we could do it backwards "permissions → list of principals".

Remember on Daybed we store it as your new format and on the API side it wasn't efficient so that we did the reverse on the API side.

from kinto.

Sorry, I find this API proposal cryptic. "shared" should reflect a state and records don't have a "shared: true/false" attribute.

Yes please change the wording, is related_principals better/enough?

from kinto.

Or even principals maybe?

from kinto.

Here is what I summarize about buckets, collections and groups following our discussions: https://github.com/mozilla-services/kinto/pull/36/files

from kinto.