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 <david.neuma...@gmail.com> 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) < > efrie...@cisco.com> wrote: > > > Do you have a suggested replacement for SSO? > > > > —Eric > > > > > On Feb 24, 2017, at 4:26 PM, Dewayne Richardson <dewr...@gmail.com> > > 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 < > mitchell...@gmail.com > > > > > > 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) < > > >> efrie...@cisco.com> 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 <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 > > >>>>> > > >>> > > >>> > > >> > > > > >
