Hi Hank, > 1. Do the tenants become the equivalent of the "groups" we are using today? I'm sorry, but I'm not familiar with that term. Could you please elaborate?
> 2. In your example, can there be children of 'Company C'? Theoratically, yes. There could be. However, I believe that adding this freedom degree might add operational complexity, so it should be limited. Is there an actual use-case of this form? > 3. Some of the APIs currently allow for 'token' authentication but, the UI portion was never implemented (AFAIK). I would like to see the 'token' authentication added so that scripts don't have to be run with user/pass. Not sure I understand what you're asking. IIUC, you're saying that token authentication should be implemented across the board. If this is indeed the case, I think it is out of the scope of the model suggested here, which only covers authorization, not authentication. > 4. I would like to see more than a single "root" user (perhaps a group that one could assign users). I agree. I described a suggested solution for that in the wiki comments. Thanks, Naama On Wed, Feb 22, 2017 at 4:03 PM, Hank Beatty <hbea...@apache.org> wrote: > Hi Naama, > > I like the idea of making Access Control hierarchical. > > I came up with some questions I thought we might think about: > > 1. Do the tenants become the equivalent of the "groups" we are using today? > > 2. In your example, can there be children of 'Company C'? > > 3. Some of the APIs currently allow for 'token' authentication but, the UI > portion was never implemented (AFAIK). I would like to see the 'token' > authentication added so that scripts don't have to be run with user/pass. > > 4. I would like to see more than a single "root" user (perhaps a group > that one could assign users). > > Thanks, > Hank > > On 02/21/2017 03:32 PM, Naama Shoresh 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 >> >> -- *Naama Shoresh* Qwilt | Work: +972-72-2221706 | Mobile: +972-52-3401999 | naam...@qwilt.com
