I think this covers all the requirements I can think of. +1. Cheers, JvD
> On Feb 21, 2017, at 1:32 PM, Naama Shoresh <[email protected]> wrote: > > Hi, > > We've been considering the subject of authorization within TO, and have > phrased a concept we'd like to share and get some feedback about. > You can find it in the wiki > <https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68715910>, > and also written below, for ease of use. > Your comments and insights are most welcome. > > ========================================================= > > The access control model concept is constructed of two dimensions: > capabilities & data. > 1. CapabilitiesCheck if a user is allowed to perform an operation > > APIs are grouped to roles, and each user is assigned a set of roles which > implies his allowed APIs. > > Example: > > API | Role > -----------------------------+----------------- > GET /ds/:id | ds-read > POST /ds/create | ds-write > POST /ds/:id/update | ds-write > POST /profile/:id/update | profile-write > > The access is checked at the entry point. A user Joe which has the roles > ds-read & ds-write is allowed to operate the following APIs: /ds/:id, > /ds/create and /ds/:id/update. > 2. DataCheck if a user is allowed to access a specific set of data. > > Here is where the concept of *tenants* is introduced: > > Every "resource" in the database is assigned (delivery-services, servers, > etc..) to a tenant. A tenant is an organization in TC. It can be either a > content-provider or an ISP. Tenants are hierarchical, where the parent is > conceptually assigned a super-set of all the resources of its children. > > Each user belongs to one or more tenants. Only the tenant's resources are > available for the tenant's users. > > * Note: for simplicitly, the example below refers to a single tenant per > user. > > Example: > > Tenant table: > > ID | Tenant-name | Parent-ID > ----+-------------+----------- > 1 | company A | - > 2 | company B | 1 // a child of company A > 3 | company C | 1 // another child of company A > 4 | company D | - > 5 | company E | - > > DS table: > > DS-Name | ... | Tenant > ---------------------+-------- > cp-a-vod | ... | 1 > cp-a-linear | ... | 1 > cp-b-vod | ... | 2 > cp-e-linear | ... | 4 > > Users table: > > Username | ... | Tenant > -----------+-----+-------- > Joe | ... | 1 > Jack | ... | 2 > John | ... | 4 > > The user Joe will be allowed to access DSs of company A, company B & > company C, namely: cp-1-vod, cp-a-linear & cp-b-vod. > The user Jack will be allowed to access DS of company B, namely: cp-b-vod. > The user John will be allowed to access DS of company D, namely: > cp-e-linear. > > Note: There will be a special "root" user that will be allowed to access > all resources. > Access Control Serice > > The authorization (access-control) functionality is contained within a new > service(s). The first APIs this service will expose are something along > these lines: > > 1. Check if a user is allowed to perform an operation. > Input: A user and an API route > Output: A boolean answer allowed/rejected > > 2. Check if a user is allowed to access a resource of a certain tenant > Input: A user and a tenant > Output: A boolean answer allowed/rejected > > > > This is a simplified description. It doesn't handle the issue of > interaction between tenants, such as assigning a delivery-service to a CDN, > which will be discussed separately. > > This email only aims to present the concepts. > > Thanks, > Naama
