Linking Toolkit to Gazelle

Linking Toolkit to Gazelle

Table of Contents

• Test sessions
  • Connectathon
  • Conformity Assessment
  • Toolkit Authorization

The Conformity Assessment environment uses both Gazelle and Toolkit but they are linked in a different way from that done for Connectathons.

Test sessions

Toolkit and Gazelle both use the term Test Session but it means something different in each system. Furthermore each system uses their Test Sessions in a different way for Connectathon vs. Conformity Assessment.

Connectathon

Gazelle creates a single Test Session for Connectathon. All activity at that event is logged under the Test Session. All vendor configurations are part of the Gazelle Test Session. The test session is identified by a number, say 53, which appears in the Gazelle URL.

Toolkit links to Gazelle at Connectathon by configuring the base Gazelle URL into toolkit.properties:

Gazelle_Config_URL=http\://ihe.wustl.edu/gazelle-na/systemConfigurations.seam?testingSessionId\=53

for example. With this configuration in place, all approved vendor system configurations can be downloaded to Toolkit using the Load all Gazelle configs button on the Toolkit Configuration tool. This makes network calls to a predefined URL off the the URL configured above pulling the OID configuration and the individual system configurations. These configurations are combined and used to generate the system configurations found in External_Cache/actors directory. Later a system-wide update can be pulled a second time in the same way or individual systems can be updated using the Reload from Gazelle button on the Systems Configuration tool. This reload can be done by the vendors since it does not require the admin password.

Note: There is a known bug (or maybe it is an inconvenient feature) in Gazelle that the OID labels that are used in the download are Test Session specific and are controlled by a configuration table. In Toolkit these labels are fixed. If Gazelle managers do not maintain a consistent configuration then this linkage between Gazelle and Toolkit breaks.

On the Toolkit side, one instance of Toolkit is used to service the entire Connectathon. The default Test Session is named default and is used by everybody. Also, the default Environment is also named default and is used by everybody.

This shared copy of toolkit has worked because vendors know that if they wish to use the Conformance tool at Connectathon using the public copy of Toolkit they had to create their own Test Session in Toolkit. The Conformance tool uses the Test Session to store test results.

Conformity Assessment

Up until now the CA configuration for toolkit was identical to that used at Connectathon except that a separate instance of Toolkit was installed for each vendor user. While Toolkit has the capacity to manage multiple vendors in a single instance, there is no privacy between vendors. Any vendor can select any Test Session, launch the Conformance tool and view the other’s results. So, we have advised the managers of the IHE CA program to install a separate instance of toolkit for each vendor under test. That has worked up until now. Privacy has been enforced via authentication to the CAS VM.

Toolkit Authorization

At the moment, Toolkit users have no privacy of Test Sessions. Any Toolkit user could view contents of another Test Session. To accommodate Toolkit users wanting private Test Sessions (and to improve focus of Test Sessions for other users), Toolkit needs to know the current User Id, which is gained through some form of authentication.

Authentication of the user credentials can be delegated to an external service provider using Open Authorization (OAuth) which provides Toolkit of the User Id token accessing the Toolkit GUI. For the test pilot of the OAuth, GitHub will be configured as the OAuth provider through the open-source component Membrane Proxy.

Prerequisite: The Toolkit administrator must complete a one-time registration of the OAuth relying web application in the OAuth provider and use the secret keys in the oauth2Resource part of the proxy’s XML configuration file.

A completed OAuth web application in GitHub should look like the image below. Important: Note the Homepage URL and the Callback URL.

github oauth app image here

Once the OAuth web application has been registered, use the Secret keys and the URLs in the serviceProxy port 9080 XML configuration file as shown below.

<router>
		<serviceProxy port="9080">
			<ssl>
				<keystore location="../../../conf/membrane.jks" password="xxx" keyPassword="xxx" />
				<truststore location="../../../conf/membrane.jks" password="xxx" />
			</ssl>
			<headerFilter>
				<exclude>X-Authenticated-Login</exclude>
			</headerFilter>
			<oauth2Resource publicURL="https://localhost:9080">
				<github
						clientId="$clientId$"
						clientSecret="$clientSecret$" />
			</oauth2Resource>
			<rewriter>
        		       <map from="^/sim" to="/sorry.html?"/>
    		        </rewriter>      
			<target host="localhost" port="8888" />
		</serviceProxy>
		<serviceProxy port="7070">
			<path>/xdstools2-4.4.0-SNAPSHOT/sim</path>
			<target host="localhost" port="8888" />
		</serviceProxy>
	</router>

Proxy is mainly used for two purposes. Granting access to Toolkit GUI through OAuth and providing access to non-TLS simulators. Toolkit GUI access is configured through the serviceProxy element Port 9080. Non-TLS simulator access is configured through the serviceProxy element Port 7070.

insert Toolkit diagram here

1. Accessing Toolkit GUI using OAuth

   1. A secure browser connection is made to Toolkit using an URL such as https://example.com:9080/xdstools2-4.4.0-SNAPSHOT/.

   2. When the proxy detects missing user authorization

      1. The proxy redirects the user’s browser to GitHub.

      2. User logs-in to GitHub and authorizes Toolkit to read their Public Profile (User Id Token).

      3. GitHub redirects the browser to the Proxy OAuth token requester.

   3. Proxy requests User Id from GitHub.

2. Accessing Toolkit Simulators

   • HTTP Port 7070 is used to access Non-TLS Simulators (through the Proxy). GUI Access through this proxy port is restricted.

   • HTTP Port 9443 is used to access TLS Simulators (No-proxy). GUI Access should not be allowed through this port through the Web Server TLS port configuration.

   • Optional providers:

     • Other OAuth providers such as CAS OAuth(*) should work in similar fashion. See this page for more details on using other OAuth providers: http://membrane-soa.org/service-proxy-doc/4.4/oauth2-openid.htm

     • Basic Authentication over HTTPS can also be used with Proxy.