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.

Detailed Profile Proposal for XUA January, 2007 : John Moehrke

Discussion

Notes from IHE Tech Face-to-Face -- March 13, 2007

The key items to accomplish this week are:

1. Develop a profile (not clear if this is transaction or content profile or just more parts of the Web-Services Appendix or XDS Actor options or something else)
2. Focus on XDS Stored Query and XDS WS-Retrieve (while being open to others if time/resources)
   1. remind audience that the use-case involves at least two different administrative domains that are operating under different technology, procedures, role-models, etc. They are cooperating in the XDS Affinity domain under an overarching policy that indicates that these differences can be rationalized. The XDS transactions are transferring control from one entity to another. This fact is important to the discussion about what is reasonable uses of the Assertion.
   2. we will be using XDS to exchange data between a simple doctor, the VA, and MASS General. It is not likely that they will all agree to the same RBAC security model. This is not necessary to have this agreed to, but it is reasonable that at the policy level they can.
   3. This results in an important fact that the XUA is usable for audit logging, but is of a lesser extent useful for access controls.
3. Leverage WS-I Basic Security Profile (version 1.1)
   1. Need Version 1.1 as it profiles SAML 2.0. http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity
      1. Not clear to me how WS-I Basic Security Profiles will handle MTOM, they both reference SOAP with attachments.
      2. Not clear to me the relationship of WS-I profiles to SOAP 1.2. WS-I seem to me to refer to SOAP 1.1 or 1.0. --> This will be profiling work that we need to do. WS-I is developing 2.0 versions of their profiles with SOAP 2.0 support. (Roberto)
   2. WS-Security header
   3. WS-Security XML Security token using SAML 2.0 Assertions
   4. Focus on Authentication and Attribute statements. NOT Authorizations
   5. Don't restrict Service Providers or Service Users from using other methods, the constraints are a minimal floor for interoperability sake.
   6. Does this impact ATNA (Node Authentication)? Do we further profile WS-I to only TLS, thus not using (allowing) XML Signatures/Encryption? Is there a reason to restrict in this way, Especially for Web-Services?
4. Leverage SAML-Protocol for the requirements of the IDP (STS), thus no new profiling from IHE
   1. Thus leveraging Liberty Alliance Certification to the SAML 2.0 standards
5. Examine the potential User Attributes for the use-cases
   1. User is Patient, Provider, Guardian, Application, Clerk, Security Admin, etc
   2. We may find useful attributes to profile:
      1. X.509 certificate compliant from ISO/TS 17090 – Health Informatics PKI, for identify management
      2. Assertion LDAP Metadata compliant from ISO/TS 21091 – Healthcare Informatics – Directory services for security, communications, and identification of professionals and patients (submitted for publication)
      3. Functional and Structural Roles from ISO/DTS 21298 (work item in committee) --- CEN 13606-4 is the same vocabulary and is normative.
      4. List of Professions from ASTM E1633 – Standard Specification for Coded Values Used in Electronic Health Record.
      5. Information access privileges from ASTM E1986 – Standard Guide for Information Access Privileges to Health Information
      6. Role vocabulary from ASTM – Privilege Management Infrastructure (work item document number not assigned)
   3. Need to make the assertion from a patient clearly indicating that the assertion is for a patient
      1. Should include the patient ID
      2. Need to be clear in the profile that there are many issues with patient access that are not handled (e.g. patient accessing lab results that have not yet been released for patient consumption, Consent, Specific provider restrictions, Specific data restrictions, Workflow of a physician that needs to discuss the data before the patient sees it, Delegates (parent, child, guardian, elder)) --> This should go into our Appendix L (policies necessary for Affinity Domain)
      3. Patient accesses XDS through some 'service' like a PHR. The PHR needs to be a member of the Affinity Domain.
      4. Need to be clear on the case where a physician is a patient... which role?
   4. When the User Assertion is about an enterprise personnel (provider, clerk, etc), then we should allow for retrieving of these attributes from PWP. Update PWP profile as necessary with attributes not found there.
6. Show at least one way that a system using EUA can get XUA Assertions
7. Show at least one way that a browser [interacting with Middleware] can obtain an XUA Assertions for use in XDS Stored Query requests (a common XUA-Consumer arrangement)
8. Show how the XUA Assertions are encoded in ATNA Audit messages
9. Show roadmap for other transactions (HL7 V3, HL7 V2, DICOM, Browsers)

The following are open issues that the IHE IT Infrastructure Technical Committee has on the XUA profile. We invite comment on these issues as they will assist with the ultimate profiling into the XUA profile.

1. Not clear if we need to define any configuration requirements. (aka SAML Metadata standard)
2. Should we rename this to “Cross-Enterprise User Assertion (XUA)” to show that we are addressing the user assertion and not the act of authenticating the user?
3. Not clear how much we need to reference WS-SX
4. There are questions around how the application calling on a service that needs XUA knows that XUA is needed?
5. There are questions around how the application calling on a service that needs XUA knows what the XUA Assertion needs to contain?
6. There are questions around error modes around the assertion, transaction, access rights (e.g. do we tell the user why it fails)?
7. Should we informatively cover an EMR/EHR doing self-assertions are a simplified model that doesn't scale well, but gets around client side lack of standards
8. How is Emergency Mode handled?
   1. One view is that this is just an infrastructure robustness issue.
   2. This must work for medical devices where the medical device includes all the standards when it is shipped from the manufacture. No ‘agent’ can be required to make this work.
   3. Do we have a well defined way for one actor to declare that it is in emergency mode? Clearly this mode doesn’t have to be accepted. Clearly the use of this mode must be carefully managed with policy.
   4. Possibly a ‘claimed’ functional role.
   5. May need to look at yet a more simple (radical) approach to user identity. This might use something simpler than SAML assertions, or might be SAML assertions in self-assertion mode.
9. Do we need to further restrict SAML transactions. (ex. Single Logout)?
10. How will this change if we institute a federated XDS Registry where the initial XDS Query transaction may be reflected and spread to multiple other Registries and possibly further?

I expect that there will be some proposals of how we can accomplish the above that we can discuss Tuesday morning.

HIMSS, IHE, Internet2, and Liberty Breakfast Panel and 2007 plan

February 28, 2007: There was a meeting sponsored by IHE, HIMSS, Internet 2, and Liberty Alliance to discuss the issues facing the healthcare industry around identity. This was organized by Michael J. McGill, PhD from Internet2.

Presentations by:

• Holt Anderson: Executive Director of NCHICA
• William Weems: The Texas Medical Center approach
• John Moehrke: On the IHE process and vision for XUA

This discussion very much made it clear that Policies must worked on. Technical solutions, no matter how elegant or complete, will fail without clear and agreed policies. There is a workgroup between Liberty Alliance and HIMSS that may be a very good place to help gather policy lessons learned and to help create boiler plate policies. It is this combined Policy work with the IHE Technical work that will make this successful.

FYI: SAML Single Sign-On (SSO) Service for Google Apps

Google Apps offers a SAML-based Single Sign-On (SSO) service that provides partner companies with full control over the authorization and authentication of hosted user accounts that can access web-based applications like Gmail or Google Calendar.

More at http://code.google.com/apis/apps/sso/saml_reference_implementation.html

See also the demo: http://code.google.com/apis/apps/sso/saml_static_demo/saml_demo.html

Presentation of XUA Scope and Plan

Some slides I put together for use at HIMSS to explain XUA and our current direction. [1]

FYI: Ping Identity white paper

Again, some interesting input to our work.

White Paper From Ping Identity Corp: February 2007, Internet-Scale Identity Systems, An Overview and Comparison http://www.pingidentity.com/InternetIdentity010707b.pdf

FYI: ZXID Version 0.8: A C library Implementing the Full SAML 2.0 Stack

John: This is not an endorsement, but simply pointing at what might be a useful toolkit.

Sampo Kellomaki, Software Announcement

ZXID is a C library that implements the full SAML 2.0 stack and aims to implement all popular federated ID management protocols such as Liberty ID-FF 1.2, WS-Federation, WS- Trust, and ID Web Services such as Liberty ID- WSF 1.1 and 2.0.

http://freshmeat.net/projects/zxid/?branch_id=65768&release_id=245917

January 29, 2007 -- Meeting Notes

Detailed Profile Proposal for XUA January, 2007 : John Moehrke

Notes:

• Will focus on XDS Stored Query and the new XDS Web-Services Retrieve
  • Need to show how future work will fill in other transactions
• Relies on the updated Web-Services clarifications also taking place this year
• Need only profile WS-I Basic Security Profile 1.1
  • Use SAML Assertions -- don't need to specify SAML Protocols
• Need to show how EUA and XUA are related
• Need to show how the SAML Assertion will be represented in the ATNA Log message
• Access Controls will NOT be required or specified. XUA should support some reasonable Access Controls.

Open Issues/Questions:

• How will XUA be published? Important to make it easy for customers to properly ask for the support and for vendors to be clear on what is truly supported.
  • Is it a full profile?
  • Do we change XDS Actors?
  • Do we add XDS Options?
    • Is this a "Global Modular Option"?
      • Might this show up as a profile with no transactions?
  • Do we use IHE Actor Grouping?
  • Is our work this year really "XUA for XDS Consumer"?
• Will we be forcing WS-Security in all transactions even when no individual user is controlling?
  • For example a system doing a pre-fetch because a patient is scheduled that day

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 meeting: IHE XUA, caBIG, Northwestern, and Project Sentinel (Georgetown University)

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 Project Sentinel / Northwestern 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 as of December 2006

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

• Detailed Profile Proposal for XUA January, 2007 : John Moehrke
• Cross-Enterprise User Authentication Draft September 12, 2006 : Tech Editor: John Moehrke
• XUA Implementation Demo 2005 Guide August 2005, John Moehrke
• WS-I Publishes New Profiles and Usage Scenarios for Public Review Working Group Drafts of Basic Profile 1.2, Basic Security Profile 1.1 and Reliable Secure Profile 1.0 Usage Scenarios, December, 2006
• Security Concepts, Challenges, and Design Considerations for Web Services Integration US Department of Homeland Security, US-CERT, Dec 14 2006

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

Project Sentinel / Northwestern XUA Testbed

Georgetown University in collaboration with Northwestern Univeristy. We plan to modify the OHF IHE Document Consumer and the NIST Registry to support SAML assertions. The plan is to demonstrate this at RSNA 2007 Annual Meeting. A proposal for such a demonstration has been submitted to the RSNA Radiology Informatics Committee for their consideration at their Feb 2007 planning retreat.

Meeting Notes:

December 12th, 2006

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