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