Cross-Enterprise User Assertion - Discussion

Introduction

IHE has defined a profile for Enterprise User Authentication (EUA) and Personnel White Pages (PWP) for use within an enterprise. The IHE is now defining transactions that cross enterprise boundaries, specifically the XDS profile and others that create an Affinity Domain. When transactions cross enterprise boundaries the mechanisms found in the EUA and PWP profile are insufficient and often nonfunctional. To provide accountability in these cross enterprise transactions there is a need to identify the requesting user in a way that the receiver can make access decisions and proper audit entries.

Cross-Enterprise User Authentication (XUA) profile will provide the user identity in transactions that cross enterprise boundaries. Enterprises may choose to have their own user directory and their own unique method of authenticating. To provide accountability in these cross enterprise transactions there is a need to identify the requesting user in a way that the receiver can make access decisions and proper audit entries.

Discussion

Dec 5, 2006 -- face-to-face ITI Tech

XUA - Look at XDS Query first year, XDS Retrieve second year. Does query need to be field-able after 1 year? For ATNA purposes, document patient ID can be retrieved by looking up URI in registry. With ATNA there may be an issue with automated pre-fetch. Handle ED differently - different cert per service with different policies. Would MTOM force f-bit encoding (data expansion)?

May want to look at 3 different environments: high, medium, low policy scopes. Should include Roles and Affinity Domain type information. Do not include authentication. What are the interoperability issues? Assertions?

IBM implementation for NHIN - Since Repository doesn't know patient ID, Registry issues timed token for retrieval (illegal in XDS). Thus the Registry acts like an intermediary for repositories. Registry controls access. -- This is not a recommended solution for IHE as the URIs returned by the registry can not be used in documents or in the future. The IHE design is such that the URIs returned can be embedded in documents or used as references in the future (likely by other people).

Discussion on the priority of our transactions to use XUA to help scope the amount of work to do this year (both profile development and product engineering). This discussion focused around using the AHIC Emergency usecase, and recognizing that data use is more important than data export. Thus the query and retrieve are the focus. The query is already a web-service, and thus should be the top priority. But it is recognized that the Retrieve is the more interesting one for two reasons. First it is the one that exposes the high-fidelity data (document vs metadata), second it is the one where the original-enterprise would still be in control as they could be using a local repository. Thus they want to know to whom they are sending the document.

The query is more likely to be automated (pre-fetch) based on an ADT, Order, or Schedule and thus less likely to be able to provide a human user identity. The Retrieve however is more likley to be a human selecting from previously pre-fetched query.

If we update the XDS-Retrieve transaction to a Web-Service, then the XUA work should include both the query and the retrieve.

Dec 12 Face-to-Face with caBIG, NW, and George Town/Internet2

Dave Channin has observed that these groups are all doing something similar and that IHE may be a good forum to bring them together into a common and interoperable solution. The first use-case that was discussed would be a workstation that needs to interact directly with XDS/XUA while also interacting with caBIG services.

Discussed the IHE solution and XUA path.

Then discussed the caBIG security architecture. In this model there is a service (Dorian) that can interact with SAML assertions (1.1 today but moving to 2.0), and returns Proxy-Certs for the same user to be used with interactions with caBIG. These Proxy-Certs are used in the TLS communications so that the caBIG can attribute the session with a user. caBIG also uses WSRF to provide session based web-services.

It was determined that Dorian could convert an XUA assertion properly. There was some non-optimal solutions for how a caBIG service could convert from the Proxy-Certs back to a SAML assertion for interactions with XUA based services (e.g. XDS). Further investigation is needed but there was some level of confidence that this could be done.

The second, and much harder, use-case is when this workstation interacts with a potential caBIG service that would need to further interact with XDS/XUA. The second use-case is much harder as the caBIG service must be able to be an intermediary for the user credentials. This is complicated because of the caBIG architecture that requires the use of proxy-certs that can not carry with them anything more than the minimal attributes defined by caBIG. Thus converting back to a SAML assertion that can be accepted by the XUA/XDS is very difficult.

Dave Channin will produce more text and diagrams. This project was named "XUA Testbed" (aka the Dave Channin XUA Project :)

Plan

1. The use-cases need to be updated to be more clinical and less technical
   1. To better communicate what we are providing
   2. To better uncover the requirements for the transactions
2. Maturity concerns
   1. There still is very limited support for SAML 2.0. The vendors are all working on it. The SAML community is all unified that 2.0 is the right one for future work. The problem appears to be vendors trying to get some revenue on existing development.
   2. WS-I and WS-SX appear to be maturing on target.
3. decide scope
   1. are we only going to focus on web-services transactions? (no support for HL7 v2 MMLP or dicom or wado or RID)
   2. we should focus year one on XDS-Query with an assumed Affinity domain Policy.
   3. Strong (Charles) request to include XDS-Retrieve as well.
      1. Would likely need to have a WS version of Retrieve. Where the old HTTP-GET retrieve never supports user (XUA) identities, where the new one has support.
      2. HITSP Emergency Responder usecase – repository wants to know the user identity that it is handing over information to.
   4. There is evidence that the XDS-Query is more likely to be done by an automated process, where as the XDS-Retrieve is more likely to be attributable to a specific user.
4. Produce a roadmap that shows how to get this done in multi-year.

References

• Cross-Enterprise User Authentication Draft September 12, 2006 : Tech Editor: John Moehrke
• XUA Implementation Demo 2005 Guide August 2005, John Moehrke

Pilot Projects

There are a few pilot projects that we are working with to gather lessons-learned so that the XUA profile can be better.

• Implementation Experiences On IHE XUA and BPPC December 5, 2006; Tuncay Namlı and Asuman Dogac, Software Research and Development Center, Middle East Technical University, Ankara, Turkey
  • Also at http://www.srdc.metu.edu.tr/publications
• Georgetown University - The meeting will be Tuesday, December 12, 2006, 8AM – 5 PM at Northwestern Radiology Imaging Informatics Lab, 448 East Ontario, Suite 300, Chicago, IL 60611. Coordinated by Dave Channen
• Eclipse Open Healthcare Framework -- Don
• GSA Pilot - Don and Lori
• European Pilot -- Emmanuel