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 >> >> >> >> >
