To answer your other question, I don't recall curl requests to be sent outside your firewall. Curl is a PHP library on the i2b2 html page. This is used for both i2b2 web client and the SHRINE webclient. Those requests are internal to your spoke server. Since the default is 443, the SHRINE default port of 6443 should not allow any of those requests to leave your firewall.
--- Keith M. Wanta UW Health From: Gpc-dev [mailto:gpc-dev-boun...@listserv.kumc.edu] On Behalf Of Wanta Keith M Sent: Tuesday, January 03, 2017 10:09 AM To: 'Dan Connolly' Cc: Lav Patel; <gpc-dev@listserv.kumc.edu> Subject: RE: SNOW authentication, client set-up? There are a few different client/server architectures in the SHRINE infrastructure. A. There is the SHRINE web client on the SNOW spoke server, if you choose to run in Apache HTTP Server (per the docs). In this case, the server would be Tomcat, running the SHRINE Adapter Cell. This authentication happens within the spoke server itself. You can define the variables defined for the 1.19.1 install here (on 1.19.2). https://wiki.ctri.mcw.edu/display/SNOW/Harvard+SHRINE+wiki+-+SHRINE+1.19.1+Install B. Each SNOW spoke server also has a Tomcat client where i2b2 is the server. C. If you are referring to the client where XML requests are being initiated from on the SHRINE Adapter Cell on the KUMC SNOW spoke server after it knows the correct XML from A, then outgoing port 6443 needs to be open on KUMC's public firewall. In return, KUMC needs to let UW Health know what the public IP address is so that UW Health can open up port 6443 as incoming and outgoing on our public firewall, so that the SHRINE broadcaster on the SNOW hub server can respond. Furthermore, KUMC needs to open up port 6443 as incoming, so that the SHRINE Adapter Cell can receive the response from the SNOW hub broadcaster. I think you are referring to C above. In that case, there is a certificate handshake that takes place for authentication to take place for each request and response. The shrine.keystore on the spoke represents the base infrastructure for the client in C above, and the shrine.keystore on the hub represents the server in C above, even though a lot more is happening behind the scenes. You will need to follow these instructions here to build your shrine.keystore. https://wiki.ctri.mcw.edu/pages/viewpage.action?pageId=44991746 --- Keith M. Wanta UW Health From: Dan Connolly [mailto:dconno...@kumc.edu] Sent: Tuesday, January 03, 2017 9:36 AM To: Wanta Keith M Cc: <gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu>>; Lav Patel Subject: SNOW authentication, client set-up? Keith, We were going over the SNOW docs with the folks at KUMC that handle the firewalls, and I couldn't tell exactly how authentication works. I didn't see much mention of a client in the docs<https://wiki.ctri.mcw.edu/pages/viewpage.action?pageId=44991731> at all. In the Linux part<https://wiki.ctri.mcw.edu/pages/viewpage.action?pageId=35488903>, I did see instructions to change i2b2_config_data.js to add a domain, but the urlCellPM is a 10.x.x.x address. Our current i2b2 web client is inside the firewall; the index.php is on the same host as jboss and i2b2, so the PHP curl call goes across localhost. Is the SNOW PM cell at MCW? If so, that curl call will have to be able to go out over the Internet to MCW, yes? What would help me is a bullet list or diagram showing exactly which HTTP messages go where when somebody logs into SNOW and issues a query and gets results. -- Dan
_______________________________________________ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
