Cross-Enterprise User Authentication

From IHE Wiki
Jump to navigation Jump to search

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.

Detailed Profile Proposal for XUA January, 2007 : John Moehrke

Discussion

January 29, 2007 -- NEXT MEETING FOR IHE XUA DISCUSSION

I think the call will focus on reviewing the text that is in the detailed profile proposal, reviewing the use-cases and assigning any missing details or missing use-cases to individuals. A stretch goal would be to discuss 'how' or 'what' IHE does. This might be as simple as an appendix on "Just use SAML" or it might include the creation of transactions and actors. I have a hard time figuring out how to make IHE Actors and Transactions out of this profile.

Detailed Profile Proposal for XUA January, 2007 : John Moehrke

Dial-in 1-877-352-0183, Conf ID 622075#, Intl 602-462-1021

9:00 - 11:00 am CT

  • 9-9:30 First discussion of XDS Web Services profile (led by Roberto)
  • 9:30-10:30 XUA profile (led by John)
  • 10:30-11 Configuration Management Whitepaper (led by Rob)

January 22, 2007 -- OpenID vs SAML

OpenID had been the topic of a few conversations, and then I find two nice articles on the topic. I think the choice is still clear that IHE must use SAML.

Comparison: OpenID and SAML Jeff Hodges, Draft Technical Report Version -00

http://www.xmlgrrl.com/blog/archives/2007/01/21/openid-and-saml-a-swirling-nexus/ OpenID and SAML: A Swirling Nexus] Eve Maler, XML Grrl Blog

January 10, 2007 -- Good news in the industry

Liberty Alliance, Microsoft Discuss Identity Protocols Jeremy Kirk, InfoWorld

Dec 12, 2006 -- 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 Pilot:)

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.

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

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.

Middle East Technical University, Turkey

See 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

Dave Channin XUA Pilot

Georgetown University, caBIG, and IHE - Meeting held Tuesday, December 12, 2006, at Northwestern Radiology Imaging Informatics Lab, 448 East Ontario, Suite 300, Chicago, IL 60611. Coordinated by Dave Channin

Eclipse Open Healthcare Framework

Don ??

HIMSS - GSA Pilot

PKI in Health Care: HIMSS/GSA E-Authentication Pilot Project

Participating RHIOS

  1. e-Health Connecticut
  2. Michigan Data Sharing & Transaction Infrastructure
  3. CHRISTUS Health of Texas
  4. Community Health Information Collaborative (Minnesota)
  5. Nevada Single Portal Medical Record
  6. Ohio Supercomputer Center Bioinformatics
  7. Virtual Medical Network (Cincinnati, Ohio)

See Presentation given to University of Minnesota's Health Informatics graduate program Dec, 2006, Pete Palmer and John Fraser

European Pilot

Emmanuel to fill in this section

Retrieved from "http://wiki.ihe.net/index.php?title=Cross-Enterprise_User_Authentication&oldid=2556"