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
