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. 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. 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. 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? 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. 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. Cindy _______________________________________________ Architecture mailing list [email protected]<mailto:[email protected]> https://lists.gpii.net/mailman/listinfo/architecture
_______________________________________________ Architecture mailing list [email protected] https://lists.gpii.net/mailman/listinfo/architecture
