Sure. I'm happy to review it in advance if you have a draft.
-- Dan ________________________________ From: Wanta Keith M [kwa...@uwhealth.org] Sent: Tuesday, January 03, 2017 10:38 AM To: Dan Connolly Cc: <gpc-dev@listserv.kumc.edu>; Lav Patel Subject: RE: SNOW authentication, client set-up? I can put together a better explanation as part of my SHRINE presentation in Kansas City. How does that sound Dan? --- Keith M. Wanta UW Health From: Dan Connolly [mailto:dconno...@kumc.edu] Sent: Tuesday, January 03, 2017 10:29 AM To: Wanta Keith M Cc: <gpc-dev@listserv.kumc.edu>; Lav Patel Subject: RE: SNOW authentication, client set-up? I don't see in your explanation an answer to my question: what is the sequence of HTTP messages? Here's the way it works at our site currently: 1. investigator's web browser -> /index.php (apache) on heron.kumc.edu: an i2b2 getUserConfig request with username, password (over internal network) 2. apache -> jboss: proxied getUserConfig message (over localhost) 3. jboss -> apache: PM cell response with session-id, list of projects, etc. (localhost) 4. apache -> investigator's web browser: proxied reply. (internal network) 5. ... stuff to set up the terminology hierarchy and previous queries elided... 6. investigator's web browser -> apache: query request with panel info and such 7. apache -> jboss: proxied request 8. jboss -> jboss: CRC cell asks PM cell if session-id is valid 9. jboss -> jboss: PM cell says yes 10. jboss -> apache: query reply with count and such (also logged to QT_QUERY_RESULTS) 11. apache -> investigator's web browser: queried reply with count and such The authorization decision made by the PM cell between messages 2 and 3. I guess you're saying that the SNOW hub delegates authorization decisions to SNOW spokes and uses SSL client certs to prevent bad guys from pretending to be spokes. Fair enough. I'd still appreciate an enumeration of message flow analogous to the above, though. How does it work at your site? -- Dan ________________________________ From: Wanta Keith M [kwa...@uwhealth.org] Sent: Tuesday, January 03, 2017 10:09 AM To: Dan Connolly Cc: <gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu>>; Lav Patel 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
