Comments in line g
> On Oct 6, 2017, at 10:31 AM, Li, Cindy <[email protected]> wrote: > > Thanks for the input, Greg. Please see my comments below: > >> On Oct 6, 2017, at 2:11 AM, Gregg C Vanderheiden <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >>> On Oct 5, 2017, at 3:02 PM, Li, Cindy <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi, Steven Githens and everyone, >>> >>> The topic might seem scary but hopefully you will think differently after >>> reading their use cases. >>> >>> This question was brought up at creating the new GPII data model >>> <https://wiki.gpii.net/w/Keys,_KeyTokens,_and_Preferences> based on >>> requirements from “keys and key tokens” document >>> <https://docs.google.com/document/d/1UoJzaEVFXEVA_CBfA5WNUHn9Y3j4JSy3tHvqeg19N1k/edit>. >>> What shows so far is OAuth2 authorization code and client credential >>> grants are not being used by any real use cases, which means we could >>> potentially remove their support from the universal repo to simplify the >>> new data model. I’m sending this email to the team to find out if this >>> understanding is correct, or if there are possibilities that they are still >>> needed in the near future. >>> >>> 1. Use case where OAuth2 authorization code grant is needed: >>> >>> One use case in the near future this grant could be used is the deployment >>> of PMT. The question is, which method will be used to deploy PMT: >>> (1) Will it be deployed as one single centralized GPII hosted website that >>> runs behind GPII firewall, has direct access to GPII Cloud database, just >>> as a part of GPII Cloud? >>> (2) Or, will it be deployed and managed outside of the GPII org. It will >>> then access cloud data via APIs provided by GPII Cloud. Or even multiple >>> PMT sites could exist to access one single GPII Cloud? >>> >>> (1) doesn’t need the use of OAuth2 authorization code grant and (2) might. >> >> >> GV2: The only thing that should be accessing the preferences are web apps >> that we create (or we control — i.e. they are reviewed by us and run under >> our control). >> >> The PMTs are included in this. >> The Discovery tools are included in this >> The explore tools are included in this. >> Even PSP (aka PCP) with memory is included in this — since the PSP with >> memory sends the information to OUR cloud - and our cloud opens the safe and >> writes it. The local computer never has access and cannot see the >> preference sets. In fact it actually doesn’t know if our cloud writes what >> is sent from the local computer — or if it modifies it in some way, >> normalizes it in some way, before it writes it into the preference safe. >> >> The BIG security hole we have — is that web apps are rendered on the local >> computer - and the local computer can therefore see what is displayed >> there. > > Even for apps or websites that are created and controlled by us, the way GPII > Cloud authenticate and authorize them could be different depending on how > they are deployed or used. For example, the security guard for a central > website hosted by GPII would be different from GPII apps installed on users’ > machines. GV: The concern I have is for apps that are in the cloud. Even if you run the app on our secure servers, if the user is using a browser to look at their preference settings — the preference setting data is displayed on the local computer — and local computer software can see (and capture) all of that information. If it can’t - then local AT won’t work— so we have a catch-22. Don’t we? That is the security hole I am talking about. and I think it is structural / functional. I don’t see a way around it other than to never allow a user to view their preferences except on a ‘trusted’ computer - whatever we decide that is. And then it is only as secure as the ‘trust’ is good. Mind bender. > >> >>> >>> I looked into Steven Githens’ dev PMT work >>> <https://github.com/sgithens/gpii-devpmt/tree/GPII-2452>, at the moment >>> it’s reading/writing preferences from json files on the file system. I’m >>> not sure if its deployment has been thought about. Please chime in if >>> anyone has ideas. >>> >> >> GV2: what file system are you referring to? We are temporarily running >> “our cloud” on the local computer. but that should end soon. > > The file system refers to the file system provided by the operating system, > on developers’ computers in this case. When a tool is at the development > stage, we usually start by reading/writing data from our own machines instead > of relying on a remote cloud support. I believe Steven’s PMT work will > eventually connect with GPII Cloud when it’s ready. GV: Correct. all of the preference tools - when used by users - should be web apps running in our controlled and secure space. If anyone knows of anything that doesn’t look like it would fit this model/statement let me know. thx > >> >>> 2. Use case where OAuth2 client credential grant is needed: >>> The only use case is First Discovery Tool, which is not really in use as >>> far as I know. Please let me know if anyone has a real case of First >>> Discovery Tool running. >> >> GV2: Not sure if it matters. It will be a cloud app — running under our >> control. That puts it in the category that you don’t care about - yes? > > It still matters as to my first comment. > GV: I don’t follow. If all preference tools (including FD tools) are cloud tools — then they fall into your category 1 — and are the same concern or non-concern would apply. No? >>> >>> Once GPII Cloud stops supporting OAuth2 client credential grant, the front >>> end of First Discovery Tool will continue to function except at the last >>> step it won’t be able to create new preferences sets on GPII Cloud. >> >> GV2: I presume you mean some old FD tool - yes? > > I meant the FD tool in this demo > <https://build.fluidproject.org/first-discovery/demos/>. It was created 2 > years ago. Do you know if it’s in use somewhere? GV: It is not being used anywhere that I am aware of. Use of it is not on any APCP roadmap (though things we learned from it are being used and code or widgets from it will likely be used). > >> >>> >>> Steven Githens again, I remember you did some work to demo First Discovery >>> Tool on your machine. Do you need OAuth2 client credential grant continue >>> to be supported? >> >> GV2: I believe that was not a real FD tool, but just a tool to let the >> libraries play with some settings on their demo machines. (which were run >> locally so that would have written to the local machine.) but that is not >> the model going forward. > > Good to know it’s not writing to the cloud. GV: It currently isn’t. But its successors will run in the GPII secure cloud and write to the GPII secure cloud. (i.e. it’s successors will be GPII Preference Tools and follow all of the PT rules ) > >> >>> >>> Look forward to your input. Thanks. >> >> GV2: Does that help? >> >> (still need to discuss the security problem with web app being visible to >> local computer. ) > > Yes, this helps. Thanks, Greg. > > I agree the concern of web app being visible to local computer worths another > topic. GV: Yea — this one has me stumped. If we make it local AT accessible — by definition software on the local computer can access the information too….. > >> >> >>> >>> Cindy >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.gpii.net/mailman/listinfo/architecture >>> <https://lists.gpii.net/mailman/listinfo/architecture>
_______________________________________________ Architecture mailing list [email protected] https://lists.gpii.net/mailman/listinfo/architecture
