Introduction

Prior to arriving at the Connectathon, it is important for participants testing XUA (or the IUA profile with the SAML Token option) to be familiar with:

• the Connectathon testing scenario
• the tool used to provide assertions for XUA tests -- the Gazelle-STS Security Token Service

The description that follows:

• explains the structure of the Connectathon tests and related tools
• describes preparation to do before you start testing XUA at the Connectathon.

Tool and SAML Token Information

Locate and use the Gazelle-STS Security Token Service:

To familiarize yourself with the Gazelle-STS tool used for Connectathons:

• Read the STS information page: https://gazelle.ihe.net/gazelle-documentation/Gazelle-STS/user.html.  That page describes how to use the tool to request, renew, cancel, and validate a security token.  
• Systems testing X-Service User and X-Service Provider should use the STS prior to the Connectathon so you are familiar with its use.

Assertions used for Connectathon testing:  

The [ITI-40] transaction (ITI TF-2: 3.40.4.1.2) specifies the SAML assertion, including that all assertions contain a Subject (principal).  The 'Subject' in the assertion could be a user or it could be an 'application'. 

For Connectathon, we have pre-defined Subjects (ie HTTP authentication users) that we use for XUA testing .  Several different Subject/users are defined, and they are associated with a different assertions used for the XUA "success" test - XUA_Transaction_with_Assertion and the "fail" test XUA_Restrict_Access.

Please refer to the Gazelle STS user manual for the list of assertions available:  https://gazelle.ihe.net/gazelle-documentation/Gazelle-STS/user.html#requesting-a-security-token.

The Gazelle-STS tool is able to generate assertions with the success and failure conditions defined in the tests.  (We expect that X-Service Users that are generating their own assertions will have less flexibility.)

Note  - Many options are possible for the AuthnStatement parameter in the Assertion. For the Connectathon, the assertions provided to the X-Service Users by the X-Assertion Providers will encode a timestamp representing when the authentication occurred and that the password class was used, eg:

• urn:oasis:names:tc:SAML:2.0:ac:classes:Password

Configuration Details:

For X-Service Users who will request assertions from the Gazelle-STS, three configuration items have been identified. When requesting a security token, the X-Service User needs to provide the X-Assertion Provider with:
   (1) An HTTP authentication user
   (2) A valid password
   (3) The 'AudienceRestriction' of the X-Service Provider

For item (3) at the Connectathon, to ease configuration, we will apply the same URL to all X-Service Providers, eg all Registries and Repositories. (Note that this URL is **not** the URL the Document Consumer will use to query a Registry or retrieve documents from a Repository).  This same, general URL used as the value of 'AudienceRestriction' for all service providers will simplify the STS configuration and will ensure that users can' access any Registry/Repository with the SAML token obtained from the STS.

The required URL is :

• http://ihe.connectathon.XUA/X-ServiceProvider-IHE-Connectathon

XUA Connectathon Test Approach

Actors in the XUA Profile can be grouped with actors in any IHE profile using webservices transactions (eg. XDS.b, XDR, PDQv3, PIXv3, RFD, XCA, many others...). Thus, you will be testing the exchange of XUA assertions in conjunction with transactions from another profile. This means you not only need to find your XUA test partners, you must also find a partner which supports a webservices transaction that you support.

Here is the sequence of activities you must do to accomplish your XUA testing during the Connetathon:

1. Before any XUA peer-to-peer tests can be run, each X-Service Provider actor must run one instance of test XUA_X-Service_Provider_Setup. Do that first.
2. The XUA profile allows X-Service User actors to get their assertions from an external assertion provider or generate their own. You need to talk to your test partners about how your system works in this regard.  
   • The Connectathon provides the Gazelle-STS (Security Token Service) tool to provide assertions used for XUA tests. 
3. You will need to find XUA test partners who support a webservices-based IHE profile that you also support.
4. There are 3 'flavors' of XUA Connectathon tests.  You can do these tests in conjunction with any webservices transaction:
   • The 'success' case (XUA_Transaction_with_Assertion test). 
   • The 'fail' case (XUA_Restrict_Access test).
   • A test where the X-Service Provider does not trust the Assertion Provider (XUA_Policy_Test).
5. When you perform XUA tests, you must use TLS and enable ATNA logging.

These notes apply to testing of the XUA profile at the Connectathon:

1. The method that the X-Service User uses to get the SAML Identity Assertion is not constrained by the XUA profile.  Test cases for this profile allow use of these two methods.  The first is most common.
   • SAML Assertion Provider -- The X-Service User will authenticate against an identity provider (XUA X-Assertion Provider).
     For Connectathon testing, we provide the Gazelle-STS tool as an X-Assertion Provider from which X-Service Users can request assertions, and against which X-Service Providers can validate assertions received. The certificate to trust in order to access that service is available here.
     The Gazelle-STS will verify signature, validity and trusted chain relations for Assertions, but will not check specific content such as AudienceRestriction value, IHE rules (or other standards business rules). This is the responsibility of the X-Service Provider, so it should not fully delegate the validation of the Assertion to the Gazelle-STS. See associated documentation here.
   • Self-assertion -- The X-Service User does not rely on an external assertion provider; rather, it generates its own valid SAML assertions
     (In this scenario, if you want Gazelle-STS to be able to verify signature and trust-chain, the certificate/or its CA signing the assertion must be available in Gazelle Security Suite (GSS) PKI. You can either use a certificate delivered by GSS, or you can contact a Gazelle Administrator to update your public certificate into GSS.)
2. XUA X-Service Providers need to be able to 'trust' assertions provided by a mix of X-Service Users who either:
   • do self-assertion
   • or, send an assertion which originated at an external STS (X-Assertion Provider). This is the more common case.
3. X-Service Providers should be configurable to 'not trust' assertions from a selected assertion provider.
4. (This test has been deferred: X-Service Providers need to be able to be configured to 'not trust' assertions containing certain parameters. For example, for the Connectathon, we will define a 'policy' that assertions containing an authentication method of 'InternetProtocol' in its AuthnStatment should fail validation.)
5. The XUA Profile constrains only a subset of the possible parameters that can be included in a SAML assertion. The proper use of these specific parameters is tested.  It is valid to include other parameters in the assertion, but these are not tested. Other parameters will not affect the validity of the assertion. The XUA X-Service Provider must accept all valid SAML assertions and process attributes profiled in ITI-40.
6. In these tests, XDS.b Document Registry and Document Repository actors which are also XUA X-Service Providers do not need to support a scenario where some Document Consumers in the Affinity Domain support XUA, and some do not. This will not be a required test at Connectathon; however, vendors are welcome to test this scenario if they wish.
7. All transactions, including those with the X-Assertion Provider, shall be done using TLS.
8. Auditing will be tested:
   • The XUA profile requires that the X-Service Provider generate an ATNA audit event for 'Authentication Failure' whenever its validation of the assertion fails. Eg. The Document Consumer must send an audit message when it initiates a Registry Stored Query. These audit events are tested in these tests.
   • The XUA profile requires that "Any ATNA Audit Messages recorded by Actor grouped with the X-Service Provider Actor, shall have the user identity recorded according to the XUA specific ATNA encoding rules" (See ITI TF-2:3.40.4.2 ATNA Audit encoding). For example: when the XDS.b Document Consumer actor records the Stored Query event, this event record will include the identity provided in the XUA Identity Assertion. This assures that the X-Service User and X-Service Provider ATNA Audit messages can be correlated at the ATNA Audit Repository. This will be tested in the XUA tests.
9. Authorization is out-of-scope for XUA (that is tested in the IUA and SeR Profiles), i.e., there are no XUA tests that allow or restrict a user's access to a document based on who a user (principal) is, nor are there tests that allow a user to see a subset of a patient's document based on the contents of the assertion. Either the validation succeeds at the X-Service Provider, and all of a patient's record is returned to the X-Service User, or validation fails, and the X-Service User receives nothing.

Evaluation

There is no result file to upload to Gazelle Test Management for this informational test. If the systems testing XUA do not do the set-up described above, then peer-to-peer XUA tests at Connectathon will not work.