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