Upload
lona
View
27
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Meeting Etiquette. Please announce your name each time prior to making comments or suggestions during the call Remember: If you are not speaking keep your phone on mute Do not put your phone on hold – if you need to take a call, hang up and dial in again when finished with your other call - PowerPoint PPT Presentation
Citation preview
Meeting Etiquette• Please announce your name each time prior to making comments or
suggestions during the call• Remember: If you are not speaking keep your phone on mute• Do not put your phone on hold – if you need to take a call, hang up
and dial in again when finished with your other call – Hold = Elevator Music = very frustrated speakers and participants
• This meeting, like all of our meetings, is being recorded– Another reason to keep your phone on mute when not speaking!
• Feel free to use the “Chat” or “Q&A” feature for questions or comments, especially if you have a bad phone connection or background noise in your environment
NOTE: This meeting is being recorded and will be posted on the Wiki page after the meeting
From S&I Framework to Participants:Hi everyone: remember to keep your phone on mute
RESTful Health Exchange (RHEx)
WebEx #7
September 20, 2012
Powering Secure, Web-Based Health Data Exchangewiki.siframework.org/RHEx
DRAFT—for discussion purposes only
Interoperability Test Framework Overview
Overview
• RHEx Overview and Refresher– RHEx Architecture
• The RHEx Test Framework– Specification Validation & Decomposition– Configuration and test profiles– Demonstration
• Summary• Questions & Wrap-up
3
4
What is RHEx (Refresher from WebEx 1)
• An open source, exploratory project to apply proven web technologies to demonstrate a simple, secure, and standards-based health information exchange
– Sponsored by the Federal Health Architecture (FHA) program
– Called RESTful Health Exchange (RHEx)
– Intended to inform a path forward on a RESTful health exchange
• A Fiscal Year 2012 project being demonstrated in 2 phases– Phase I: Security approach for a RESTful health information
exchange (April-July 2012)
– Phase II: Content approach for a RESTful health information exchange (July-September 2012)
Download the recording or briefing from the 1st WebEx here: http://wiki.siframework.org/RHEx+Materials
5
RHEx Architecture Stack
Phase 1
Phase 1
Phase 2
Key
6
Overview – the RHEx Test Framework
• Built to validate conformance testing initially against the RHEx profiles and associated specifications
• Runs against a set of URLs defined on a configuration file, so can be run against any server that implements RHEx service interfaces
• Results of such conformance testing may become input to certification testing, particularly for those components affecting security through OpenID Connect
Phased testing withRHEx Test Framework
Test Framework
7
Specification Validation
Security SpecificationsOpenID Connect
OAuth 2.0
JSON Web Token
8
Phase 1
Phase 2
Testing in 3 steps
1. Decompose and derive valid test assertions requirements from identified, technical specifications– Each test assertion will map to a
particular SHALL, MUST, or SHOULD statement in a relevant specification
2. Test the test assertions using a developed automated Testing Framework
3. Document results
9
Specification Decomposition
6.5.4 DELETEThis operation MAY be implemented. If a DELETE is sent to the document URL, the document is completely deleted. If DELETE is implemented, special precautions should be taken to assure against accidental or malicious deletion. Future requests to the section URL MAY return a status code of 410, unless the record is restored.Status Code: 204, 410
The decomposition and resulting test assertions for this requirement would be defined as follows:
1. If DELETE operation is not implemented, the server MUST respond with a status code of 405 (section 6.1.2).
2. If DELETE is successful the server must respond with 204 status code (implied requirement).
3. If DELETE operation is successful, then future requests to the document URL MAY return status code 410 unless the record is restored.
4. If target of deletion does not exist then server should respond with 404 not found HTTP status code (implied requirement).
OMG RESTful Transport Specification: Section 6.5.4
10
Test Assertion status codes
PASSED Test passed and was successful. PASSED with
WARNINGS Test passed and was successful with some warnings.
SKIPPED (or missing input)
Test was skipped and not executed because either its inputs were missing (i.e., the input required to process the test assertion was missing) or one of its prerequisite tests was not found or not loaded.
PREREQ_FAILED The test assertion was not processed because a pre-requisite (dependent) test assertion failed.
FAILED RECOMMENDATION
Test fails to meet a recommended or optional (e.g., SHOULD, RECOMMENDED, etc.) element of the specification. This is treated as a warning such that a test assertion failed, but the type attribute for the test assertion indicated that it was “recommended,” not “required.” This type of failure will not affect the overall conformance result.
FAILED Test failed to meet a mandatory (MUST, SHALL, etc.) element of the specification. This designation indicates the target system fails to conform.
The final status of each test assertion is assigned a designation as follows:
11
Sample Test Report
Here’s sample report running against the RHEx Patient Data ServerTest Id Section Description OperationContext Initial
6.2.5.0 6.2.5 baseURL (OPTIONS)6.2.5.1 6.2.5 OPTIONS on HDR baseURL MUST return 200 status
code (implied contentType = text/xml??)OPTIONS HDR baseURL
W
6.2.5.2 6.2.5 X-hdata-security HTTP header MUST be included in response
OPTIONS HDR baseURLP
6.2.5.3 6.2.5 Response SHOULD NOT include an HTTP body (RECOMMENDED)
OPTIONS HDR baseURLF
6.2.5.4 6.2.5 Implied: if baseURL not defined (HDR not found) should return 404 status. (RECOMMENDED)
F
6.3.0 6.3.0 baseURL/root.xml (GET)6.3.1.1 6.3.1 baseURL/root.xml GET [MUST] returns XML object
with 200 status code as defined by the HRF specification (implied contentType = text/xml; namespace = HRF: WARN if not met)
GET baseURL/root.xml
W
6.3.1.2 6.3.1 Implied: if baseURL not defined (HDR not found) should return 404 status. (RECOMMENDED)
GET baseURL/root.xmlP
6.3.2 6.3.2 baseURL/root.xml (non-GET)6.3.2.1 6.3.2 baseURL/root.xml POST operation MUST NOT be
implemented. Returns 405 statusPOST baseURL/root.xml
F
6.3.2.2 6.3.2 baseURL/root.xml PUT operation MUST NOT be implemented. Returns 405 status
PUT baseURL/root.xmlF
12
Testing FrameworkFunctional Components
Validation Process Control• This function controls all processing within the testing
tool.
Set-up Context• Manages the configuration properties for the test client
with implementation-specific details such as the base URL and supported XML files to publish as documents.
• Optionally initializes the context to any implementation-specific details such as security and authentication with hooks in place to perform pre- and post-actions on each HTTP request.
Test Assertion Executor• Builds a test plan to execute test assertions in a valid
order• Execute the test assertion components handling any
exceptions.• Test assertion components validate particular
requirements is implemented correctly
Build Conformance Report• Output from the analyzer tool is a conformance report. • As the test assertions are processed, the conformance
report is built based on output from the validation functions.
13
Overview
• RHEx Overview and Refresher– RHEx Architecture
• The RHEx Test Framework– Specification Validation & Decomposition– Configuration and test profiles– Demonstration
• Summary• Questions & Wrap-up
14
simpleConfig.xml<?xml version="1.0" encoding="UTF-8" ?><configuration> <loginURL> http://rhex-simple:3000 </loginURL> <defaultUser>
<email>[email protected]</email> <password>password</password> </defaultUser> <user2>
<email>[email protected]</email> <password>password</password> </user2> …. <noaccessUser>
<email>[email protected]</email> <password>password</password> </noaccessUser> <HttpRequestChecker> org.mitre.rhex.security.RhexOpenIdConnectSecurityChecker </HttpRequestChecker> <baseURL> http://rhex-simple:3000/patients/1 </baseURL> <invalidBaseURL>http://rhex-simple/patients/NotValid</invalidBaseURL>
<document><url> http://rhex-simple:3000/uploads/document/attachment/1/vitalSign.xml </url><!-- include content (e.g. id) from test document to verify document was loaded correctly --><content><![CDATA[ <id>8f37e9a12a10020004000080</id> ]]></content>
</document> <profileDocumentFile> profiles/simpleProfile.xml </profileDocumentFile>
</configuration>
This slide shows configuration customized to an instance of the RHEx Simple Web App
15
profiles/simpleProfile.xml
<?xml version="1.0" encoding="UTF-8"?><assertionProfile>
<description> This document contains the test assertions for the Simple Profile definition for the RHEx SimpleWeb Application. These test assertions are used by the testing tool to determine if server implementing the RHEx data interface is conformant to the Simple Profile. </description> <testAssertion class="org.mitre.rhex.BaseUrlNotFoundTest" id="6.2.1.1"/> <testAssertion class="org.mitre.rhex.BaseUrlGetHtmlAcceptTest" id="6.2.1.5" /> <testAssertion class="org.mitre.rhex.BaseUrlRootXmlNotFound" id="6.3.1.2"/> <testAssertion class="org.mitre.rhex.SectionNotFound" id="6.4.1.2"/> <testAssertion class="org.mitre.rhex.openid.UserDocumentGetTest" id="C.2.1" /> <testAssertion class="org.mitre.rhex.openid.UserAccessTest" id="C.2.2" prereq="C.2.1" /> <testAssertion class="org.mitre.rhex.openid.MultiUserSessionTest" id="C.3.0" /> </assertionProfile>
16
17
DemoTest against the RHEx
Simple Web App
<?xml version="1.0" encoding="UTF-8" ?><configuration> <loginURL> http://rhex:3000/</loginURL> <defaultUser>
<email>[email protected]</email> <password>password</password>
</defaultUser>
<HttpRequestChecker> org.mitre.hdata.test.RhexOpenIdConnectSecurityChecker </HttpRequestChecker> <baseURL> http://rhex:3000/records/3 </baseURL> <invalidBaseURL> http://rhex:3000/records/NotValid </invalidBaseURL>
<updateDocumentUrl> http://rhex:3000/records/2/conditions/4f985c3ad7d76a6d830000d6 </updateDocumentUrl> <documentSection> vital_signs </documentSection> <updateDocumentFile> data/vitalSign.xml </updateDocumentFile> …
<profileDocumentFile> profiles/basicProfile.xml </profileDocumentFile>
</configuration>
rhexOidcConfig.xml
18
profiles/basicProfile.xml<?xml version="1.0" encoding="UTF-8"?><assertionProfile>
<description> This document contains the test assertions for the Basic Profile definition. These test assertions are used by the testing tool to determine if server implementing the RHEx interface is conformant to the Basic Profile. </description> <testAssertion class="org.mitre.rhex.BaseUrlGetTest" id="6.2.1.4" /> <testAssertion class="org.mitre.rhex.BaseUrlOptions" id="6.2.5.1" /> <testAssertion class="org.mitre.rhex.BaseUrlRootXml" id="6.3.1.1" /> <testAssertion class="org.mitre.rhex.BaseSectionFromRootXml" id="6.4.1.1“prereq="6.3.1.1" /> <testAssertion class="org.mitre.rhex.RootXmlAtomCheck” id=“6.2.1.6” prereq=“6.2.1.4, 6.3.1.1” /> <testAssertion class="org.mitre.rhex.SectionPut" id="6.4.3" prereq="6.4.1.1" /> <testAssertion class="org.mitre.rhex.BaseUrlRootXmlPut" id="6.3.2.2"/> <testAssertion class="org.mitre.rhex.DocumentNotFound" id="6.5.1.2" prereq="6.4.1.1" /> <testAssertion class="org.mitre.rhex.DocumentUpdate" id="6.5.2.1" /> </assertionProfile>
19
Test Unit Dependencies
• BaseUrlGetTest id=6.2.1.4– 6.2.1 GET Operation on the Base URL
Server MUST offer an Atom 1.0 compliant feed of all child sections specified in HRF specification, as identified in corresponding sections node in the root document
• BaseUrlRootXml id=6.3.1.1– 6.3.1 GET baseURL/root.xml
GET operation MUST return an XML representation of the current root document, as defined by the HRF specification
• RootXmlAtomCheck id=6.2.1.6, req=6.2.1.4, 6.3.1.1– Check consistency between root.xml and atom feed
20
21
BaseUrlRootXml[6.3.1.1]
BaseSectionFromRootXml
[6.4.1.1]
DocumentTest
[6.5.1.2]
DocumentCreate
[6.4.2.2]
DocumentCreateCheck
[6.4.2.3]
DocumentDelete
[6.5.4.1]
DocumentFutureDelete
[6.5.4.3]
RootXmlAtomCheck
[6.2.1.6]
BaseUrlGetTest[6.2.1.4]
Chaining Tests
root.xml
atom feed
22
DemoTest against the RHEx
Patient Data Server
Overview
• RHEx Overview and Refresher– RHEx Architecture
• The RHEx Test Framework– Specification Validation & Decomposition– Configuration and test profiles– Demonstration
• Summary• Questions & Wrap-up
23
24
Key Features of the RHEx Test Framework
• Test Framework is a generic testing framework– Framework not tied to any specific health or security standard– Underlying API to create new tests and extend to new specifications– Schedules tests based on dependencies– Executes tests and generates report with status and errors/warnings
logged• Abstracts test implementation from configuration and most server
implementation details– Most inputs consist of a URL that can be configured to one of many
implementations (see simpleConfig.xml as example)• Chaining tests allows tests to be as fine grain as possible and focus on a
discrete test assertion– Keeps tests simple!!!– Tests can use any of the requests, responses, and inputs for other tests
so don’t need to duplicate requests• Abstracts set of tests to run from configuration
– Configuration file selects Test Profile to execute (see basicProfile.xml)– Test profile can be executed in different configuration contexts
25
Helping the ONC/RHEx Certification Process
• RHEx Test Framework runs against a set of URLs defined in the configuration file– Can be configured and run against any server that implements RHEx service
interfaces– Test framework software can be downloaded by partners using public website
github.com
• Results of such conformance testing can become input to possible future certification testing– Certification will require that relevant standards are correctly implemented; the test
framework can demonstrate this– This is particularly useful to verify those components affecting security through
OpenID Connect
• Suggest making the Test Framework Tool part of the ONC certification testing toolkit
Questions & Wrap-up
• Questions?
• This FY12 project seeks community engagement:
– Visit the RHEx wiki for more information
– Join the community discussion on Google Groups
– Participate in the RHEx WebEx meetings (see S&I calendar)
• Only one left – September 27, Thursday, 11 am – 12 pm EDT
• Let us know if you would like additional information
26
Powering Secure, Web-Based Health Data Exchange
http://wiki.siframework.org/RHEx
27