Lets get together and talk about this. I think we have done the best we can from email. And need to clarify some issues and start making some decisions.
We are now moving out of the 'explore and keep all our options open' stage and into the production build for stability, maintenance, and Security stage. Of course we don’t want to shut the door as me don’t need to but we need to start blocking down some of the hatches. So let’s put together a team that covers the issues and aspects here and reach some conclusions and decisions. I am guessing Brendan, Colin, Cindy, Steve, Antranig, Sandra, Gregg. anyone else? Obviously we are not meeting for a week or two. Cindy do you need answers faster than that? g Gregg C Vanderheiden [email protected] > On Oct 6, 2017, at 2:06 PM, Steven Githens <[email protected]> wrote: > > Hi Cindy et all! > > Thanks for bringing this up, and also putting together the data model schema > and documentation. I think hammering out the data model and stamping a > version number on it at some point is of pretty high importance. > > I would recommend that we don't remove the OAuth and related security > mechanisms from the data model, if the only reason for removing them is that > we aren't using them yet. If there are other strong reasons for removing > them, then maybe there is potential to take them out. While my previous work > on prototyping new interfaces and workflows based on the first discovery code > base is no longer active, I think it's inevitable that we'll be building some > sort of tool in the next few years that allows an individual to define their > experience at that level of immersion. I don't know if it would be more > effort to maintain any bit-rot that occurs in the OAuth2 Client Credential > Grant until then, or to remove it now and re-introduce a similar > functionality when the time for it arrives. > > For the OAuth2 Authorization Code Grants, I think it would probably be much > easier for us to deploy everything behind a single central domain, at least > initially. However, having watched our use cases and requirements fluctuate > through the history of the project, I wouldn't be surprised if we needed the > cloud data API's to interact between multiple instances. Again... I think it > would make more sense to keep it in if the overhead of maintaining the few > extra document schema's was much lower than reintroducing the functionality > in the future. I don't know enough of the nuts and bolts of OAuth to know if > that's true. > > For my PMT, it is reading and writing from disc at the moment, but I really > ought to make it properly communicate through the server (even if the entire > stack is still running on the local machine). If I was to add this to the > DevPTT or another PMT, is there a small sample/demo app we have that I could > take a look at? Actually, given that I'm using gpii-express and a large > swath of Tony's related libraries, I would love to be able to bolt on > gpii-express-user to at least put some initial security on the tool. Whether > that usage would act as a direct sort of admin/clinician account to the > database, or whether it would connect using an OAuth2 authorization code > grant is a bit up in the air. > > Thanks Cindy! > Steve > > > >> On Oct 6, 2017, at 9:05 AM, Li, Cindy <[email protected] <mailto:[email protected]>> >> wrote: >> >> Comments inline as well. >> >>> On Oct 6, 2017, at 11:39 AM, Gregg C Vanderheiden <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Comments in line >>> >>> g >>> >>> >>> >>>> On Oct 6, 2017, at 10:31 AM, Li, Cindy <[email protected] >>>> <mailto:[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. >> >> Understand your concern. It’s complicated enough to use a separate topic. >> >>> >>> >>>> >>>>> >>>>>> >>>>>> 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? >> >> Although all preference tools are cloud tools that controlled by us, they >> don’t necessarily fall into category 1. An example is GPII apps installed on >> users’ computers. These apps use cloud APIs to read and help PCP with memory >> to write to the cloud. OAuth is required to protect these APIs. >> >>> >>> >>> >>> >>> >>> >>> >>> >>>>>> >>>>>> 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). >> >> This information very helpful. Thanks. >>> >>>> >>>>> >>>>>> >>>>>> 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 ) >>> >> I guess its successors will be other tools like PCP or PMT instead of the >> same tool being hooked back up with GPII 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. >>> >>> 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
_______________________________________________ Architecture mailing list [email protected] https://lists.gpii.net/mailman/listinfo/architecture
