Jeremy, > the requests of that google doc would be satisfied.
Great. Thanks for that verification. > ^^ maybe these 2 roles are "seeded" in the roles table. so out of the box, > you get 2 roles and that 2nd role is very important because > ldap-authenticated users (with no user in the users table) get that role... I don't think this seeding is necessary, if the "role group" level is added. I elaborated on this subject in a reply to your comment in the wiki. Naama On Wed, Feb 22, 2017 at 8:08 PM, Jeremy Mitchell <[email protected]> wrote: > FYI, here is what our wholesale group has asked for regarding access > control. > > https://docs.google.com/document/d/1kPw45vcqJfR3b_ > xmXMUxy9ibhWvuBJhZ7xWoi3JlC6E/edit#heading=h.i2v3ngs94gst > > So with: > > - a tenant hierarchy to restrict scope > - dynamic roles (not sure if this is something everyone thinks is a good > idea or not) > > the requests of that google doc would be satisfied. > > Jeremy > > > On Wed, Feb 22, 2017 at 10:33 AM, Jeremy Mitchell <[email protected]> > wrote: > > > +1 on Dave's question. ldap is an edge case that we probably have to > > account for. so with this new approach, 2 things are checked - your role > > (what you can do) and your tenancy (scope of what you can do). > > > > first one - role: > > > > we'll need to think how ldap authenticated users (that don't have an > > actual row in the users table) are automatically assigned a role. Maybe > the > > roles table is seeded with 2 roles like this: (remember, a role is a > > grouping of "capabilities" (or apis) ) > > > > admin > > - GET /api/ds > > - GET /api/ds/:id > > - PUT /api/ds/:id > > - POST /api/ds > > - DELETE /api/ds/:id > > - everything other api that TO supports > > > > read-only > > - GET /api/ds > > - GET /api/ds/:id > > - every other GET api that TO supports (but make sure only GETs that are > > reads. we have some GETs that do more than reading :) ) > > > > ^^ maybe these 2 roles are "seeded" in the roles table. so out of the > box, > > you get 2 roles and that 2nd role is very important because > > ldap-authenticated users (with no user in the users table) get that > role... > > > > 2nd one - tenancy: > > > > how do we assign tenancy to these ldap-authenticated-has-no-user-row > > users? i would probably suggest they get assigned "root tenant" which is > > the parent of all tenants thus eliminating scoping altogether. > > > > to summarize, i'd suggest ldap-authenticated users (with no user entry in > > the user table) get: > > > > - the seeded read-only role > > - the root tenant > > > > And one more thought regarding roles. I mentioned 2 seeded roles (admin > > and R/O) but IMO an admin should be able to create N number of roles / > api > > combinations. For example, maybe I have a someone that wants access to > one > > and only one API, i could create the "john_role" that contains that one > api > > and assign that role to john. My point is, the roles table could be > > dynamic....whoever administers TO can set up the roles as they see fit.. > > > > Jeremy > > > > On Wed, Feb 22, 2017 at 9:11 AM, Eric Friedrich (efriedri) < > > [email protected]> wrote: > > > >> Will the introduction of the new Access Control Service (and API) > require > >> two new HTTP API calls for every call from the user to the API? > >> > >> I’d also like to second two of Hank’s requests below for #3 and #4. > >> > >> —Eric > >> > >> > On Feb 22, 2017, at 9:03 AM, Hank Beatty <[email protected]> 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 | [email protected]
