I've edited the wiki page <https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68715910>, polished the terminology a little and added some details to the capabilities model.
Regards, Naama On Sat, Feb 25, 2017 at 1:34 AM, Nir Sopher <[email protected]> wrote: > 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 > > > > >>>>> > > > > >>> > > > > >>> > > > > >> > > > > > > > > > > > > > > -- *Naama Shoresh* Qwilt | Work: +972-72-2221706 | Mobile: +972-52-3401999 | [email protected]
