Currently, if you have LDAP configured, when a user tries to login to Traffic Ops, Traffic Ops will first check the database and then check LDAP. If a user is not in the database, but is in LDAP, the user will be allowed to access Traffic Ops with read-only permissions. Are we planning on keeping this functionality in the new model?
On Wed, Feb 22, 2017 at 7:03 AM, 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 >> >>