> On Oct 5, 2017, at 3:02 PM, Li, Cindy <[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. > > 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. > 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? > > 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? > > 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. > > 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. ) > > Cindy > > _______________________________________________ > Architecture mailing list > [email protected] > https://lists.gpii.net/mailman/listinfo/architecture
_______________________________________________ Architecture mailing list [email protected] https://lists.gpii.net/mailman/listinfo/architecture
