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