Looks good to me. Furthermore, as you mentioned when we discussed it, a user that have no tenancy will be allowed to access only delivery-services with no tenancy.
The purpose of the "optional" phase is to allow an "old mode knob" as well as ease the transition of the different Traffic-control deployments. During this period, the TC owner will be able to set elements tenancy as well as align with the API adjustments. I suggest that on the release to follow, tenancy will become mandatory, so we do not have 2 different variants of deployments. If the feature is not in use, the TC owner should just work with a single tenant. Nir On Sat, Feb 25, 2017 at 12:25 AM, Jeremy Mitchell <[email protected]> wrote: > Going forward with this approach of roles (what you can do) and tenancy > (what scope you are restricted to) should tighten up the holes and make it > much easier to see what a role can / cannot do as roles will be mapped to > api endpoints. The way roles are setup today, it is hard to discern what > each role can actually do so I'm not surprised the read-only role is a > little too loose. > > To summarize a bit (Nir or Naama, correct me if I'm wrong). > > For phase 1: > > A user will have one role. A role has N capabilities. A capability has N > apis. > A user will have one or no tenant. > A deliveryservice will have one or no tenant. > A cdn will have one or no tenant. > > Example: > > Jeremy has the DS Manager role that has the ds-read and the ds-write > capabilities. ds-read is GET /ds and GET /ds/:id. ds-write is POST /ds and > PUT /ds/:id > Jeremy has the Foo tenant > > This means Jeremy can access these api endpoints: > GET /ds (get all ds's) > GET /ds/:id (get one ds) > POST /ds (create a ds) > PUT /ds/:id (update a ds) > > but...only for ds's that belong to the Foo tenant. > > Bob has the Server Manager role that has the server-read and the > server-write capabilities. server-read is GET /servers and GET > /servers/:id. server-write is POST /servers and PUT /servers/:id > Bob has the Bar tenant > > This means Bob can access these api endpoints: > GET /servers (get all servers) > GET /servers/:id (get one server) > POST /servers (create a server) > PUT /servers/:id (update a server) > > but...only for the servers that belong to the cdn that belong to the Bar > tenant. > > also, you'll see that by making tenant optional on user, ds and cdn, it > will allow everyone to ease into this tenancy model. if a ds has no > tenant...then anyone can see it... > > Jeremy > > On Fri, Feb 24, 2017 at 2:37 PM, David Neuman <[email protected]> > wrote: > > > From what I understand, LDAP is not the issue, it is the fact that we > give > > everyone read-only by default and read-only users can get sensitive > > information. I think we want to keep LDAP but not allow read-only? > > > > On Fri, Feb 24, 2017 at 2:31 PM, Eric Friedrich (efriedri) < > > [email protected]> wrote: > > > > > Do you have a suggested replacement for SSO? > > > > > > —Eric > > > > > > > On Feb 24, 2017, at 4:26 PM, Dewayne Richardson <[email protected]> > > > wrote: > > > > > > > > re: Dave on LDAP > > > > > > > > LDAP should be avoided as we are now finding that it's not a > > preferrable > > > > way of logging in based upon Security Concerns. If needed for some > > > reason > > > > down the road we should consider it as a separate Micro Service that > > can > > > be > > > > "bolted" on. > > > > > > > > -Dew > > > > > > > > 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 > > > >>>>> > > > >>> > > > >>> > > > >> > > > > > > > > >
