Dave, > 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?
I don't think I can answer that question, but whether the answer is yes or no, the suggested model can cover it. If the answer is "yes", then, as Jeremy mentioned, LDAP users should receive the full set of read-only roles, upon login. If the answer is "no", there would probably be some granularity described in LDAP and translated to TC roles. Does this make sense to you? On Wed, Feb 22, 2017 at 5:09 PM, Dave Neuman <neu...@apache.org> wrote: > 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 > >> > >> > -- *Naama Shoresh* Qwilt | Work: +972-72-2221706 | Mobile: +972-52-3401999 | naam...@qwilt.com
