Cross-Enterprise User Assertion (XUA) Profile

Introduction

This is a draft of the Cross-Enterprise User Assertion Profile (XUA) supplement to the ITI Technical Framework. This draft is a work in progress, not the official supplement or profile.

Profile Abstract

The Cross-Enterprise User Assertion Profile (XUA) defines a set of claims about an authenticated principle (user, application, system...) using a transactions that may cross enterprise boundaries. Enterprises may choose to have their own user directory and their own unique method of authenticating the users, they may even choose to use a third party. 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.

Issue Log

See Cross-Enterprise User Assertion - Discussion

Glossary

Add the following items to the Glossary 

XUA

Cross-Enterprise User Assertion (Formerly Cross-Enterprise User Authentication)

User Assertion

blah blah

Volume I

Add the following bullet to the list of profiles in section 1.7 

• Cross-Enterprise User Assertion - provides 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 the users, they may even choose to use a third party. 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.

Dependencies

Add the following row(s) to the list of dependencies in section 2.1

Integration Profile	Dependency	Dependency Type	Purpose
Cross-Enterprise User Assertion	None	None

Add the following section to the section 2.2

2.2.n Cross-Enterprise User Assertion (XUA)

Cross-Enterprise User Assertion (XUA) provides 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 the users, they may even choose to use a third party. 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.

Add the following section to Vol 1

Cross-Enterprise User Assertion (XUA) Integration Profile

The Cross-Enterprise User Assertion Profile (XUA) provides a trustable user identity for transactions that cross enterprise boundaries. The user identities may be centrally managed, or distributed.

There are transactions defined by IHE that cross enterprise boundaries. The existing IHE mechanisms to provide an authenticated user identity (EUA) will not function in cross-enterprise transactions. Further in a cross-enterprise environment it is more likely that the transactions will be going between two enterprises that maintain their own independent user directories (PWP). This problem is the same focus of the OASIS-SAML standard. This standard has received much attention and support by the security and the platforms industry. This standard allows for centralized user directory, but also supports the more powerful federation of user directories. This standard supports many methods of user authentication (password, biometrics, smartcard) and can include details about the method(s) used.

The solution proposed is to leverage SAML and the various profiles from W3C, OASIS, and WS-I. In this way we will be able to take advantage of the vast experience of the communities outside of healthcare standards. This profile will be leveraging the experience of a few programs around the globe that have started work with SAML in healthcare. Most of these projects are applying SAML to XDS as we expect to be doing in the first year.

Discussion about the creation of this profile can be found at Cross-Enterprise User Assertion - Discussion

Use Cases

This profile will likely take two years to fully fill out. In the first year we will be focusing only on the consumption side of XDS, specifically the Registry Stored Query and Retrieve Document transactions. The motivator for this is that these are the most exposed transactions that IHE has defined; their use is expected to be from a wide variety of consuming applications and enterprises.

Most of the use-cases involve 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. They 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. This results in an important fact that the XUA is usable for audit logging, but is to a lesser extent useful for access controls.

1. Country that provisions users into a single assigning authority domain (e.g., Germany) and handles all user authentication requests
   • Support for centralized user directories
2. Region that knits together many competing hospitals and clinics where each hospital/clinic manages their own users.
   • Support for distributed user directories
3. Patient that wishes to use their ISP as their authentication authority uses a PHR like application to access their own information in XDS.
   • Support for third party user directories
4. User using Registry or Repository is the patient. They are using an authorized PHR service which is handling the XDS Consumer responsibilities (including ATNA). The service provider wants to restrict the information returned to those that have been released for patient consumption (for example a lab result that regulations require the provider to discuss in person before releasing the information)
   • User needs to be identified as the patient
5. Hospital issues identity badges with picture and name printed, RFID for building access, and smart-card for strong authentication
   • Support for strong authentication methods such as smart-cards
6. Small clinic in a rural setting supports a dozen users using passwords.
   • Support for small scale systems that use passwords
7. General practice doctor retrieving results of a test performed by an outpatient clinic, where the outpatient clinic wants to have an audit trail specific to the user requesting.
   • Support for the service provider to get a user identity for audit log purposes
8. System, based on a scheduled procedure, pre-fetches the available documents so that it can determine a relevant few documents to offer to the doctor when the patient arrives.
   • Support for identifying the user as the system for tasks that are not initiated by a human user
9. Access of a document by an individual that can’t be identified because the SAML-IDP (X-Assertion Provider) is not accessible
   • Not clear if this is in scope, or is a performance criteria for implementor
10. User acting in an identified clinical role accesses the Registry where the Registry wants to know the user identity and the role they are acting in.
    • Support inclusion of functional roles as named vocabulary
11. Specialized XDS for Emergency Dataset. In this case the transfer of information to the XDS Consumer is not critical to fully control, and thus the administration is willing to accept requests from any system as long as they can provide a user-assertion from a trusted source. This trusted-source may be a specialized IDP for First Responders. (See RSA Pilot)
    • In this case only a user identity with proper linkage to a trusted IDP is needed. No specific attributes are needed.
12. User using a Cross-Community-Bridge needs to provide a user assertion that can be utilized by the Cross-Community-Bridge.
    • This requires that the Assertions can be re-purposed for the next Bridge or Reg
13. Patient has requested that a named doctor not be given access to their documents.
    • Support for the service provider to augment access controls based on some non-specified rules that are specific to the user
14. User using Registry or Repository where the service provider wants to be assured that the user has been authenticated to a specific assurance level. This is not a case of not trusting the system, but recognition that the requesting supports different levels of authentication. For example the system supports a proximity card as a form of authentication, as well as Smart-Card with PIN. This is not a replacement for ATNA access controls which give distributed access controls.
    • User Identity with level of assurance of that identity is needed.
15. Doctor in an emergency situation request to retrieve documents that would under normal conditions would not be accessible because the privacy consent (BPPC) has restricted access
    • Support for Emergency override (aka Break-Glass)

Solution

The vast majority of the use-case needs are captured in the SAML 2.0 Assertion. This is a mature standard produced by OASIS. For our first year we have two transactions that utilize Web-Services, and thus we will specify that when a Cross-Enterprise User Assertion is needed that these Web-Services transactions will additionally use the Web-Services Security header with a SAML 2.0 Assertion. As with any IHE profile, the applications are not forbidden to use other methods of providing the user identity.

This profile will show how to reference a SAML 2.0 Assertion in an ATNA Audit Message.

The method of authenticating the user and the method that the XDS-Consumer uses to get the SAML 2.0 Assertion is outside the scope of this profile. There is no identified interoperability problem in this transaction as the space is well specified and products certified by Liberty Alliance. One method of authenticating the user is defined in the Enterprise User Authentication Profile. When EUA is used to authenticate the user, this profile will show how to obtain the SAML 2.0 Assertion. A specialization of this interaction is when the user is using a web browser and the XDS-Consumer actor is implemented by web-middleware. In this case the SAML Browser SSO Profile may be utilized by the middleware to obtain the SAML 2.0 Assertion. All other authentication types are left undefined, but allowed.

There are user attributes that appear to be needed in the use-cases: Doctor, Patient, Guardian, Emergency-Access. The SAML 2.0 Assertion can contain attributes about the user. At this time it is not clear what standards to use to identify these attributes and their values, so this is left to specific implementations that have defined a local vocabulary or vocabulary translation.

The method used by the XDS-Consumer to determine the contents of the SAML 2.0 Assertion is outside the scope of this profile. This profile will show in an informative way how to utilize SAML Metadata, and WS-Policy.

It is expected that extending this solution to HL7 and DICOM will be supported in the future.

Actors/Transaction

Cross-Enterprise User Assertion Actor Diagram

Cross-Enterprise User Assertion Actors and Transactions

Actor	Transaction	Optionality	Section
X-Service User	Provide X-User Assertion	R	ITI-A
X-Service Provider	Provide X-User Assertion	R	ITI-A

Options

Cross-Enterprise User Assertion Options

Actor	Option	Section
X-Service User	None
X-Service Provider	None

Process Flow

Cross-Enterprise User Assertion Process Flow

In the above flow we are showing more actors than are specified in this profile. The User Authentication Provider, User Directory Provider and X-Assertion Provider are not profiled here, but rather are shown to give a context to the XUA transactions.

Actor Definitions

Add the following Actor Summary Definitions in Appendix A 

X-Assertion Provider

This is a SAML Identity Provider (IDP), and is not further specified by IHE.

X-Service User

This is the system making a web-services request. In the first year this is the XDS-Document Consumer Actor.

X-Service Provider

This is the system providing the web-service. In the first year this is the XDS-Document Registry and XDS-Document Repository Actors.

Transaction Definitions

Add the following Transaction Summary Definitions in Appendix B 

Provide X-User Assertion

This transaction provides a trustable user assertion from the service requester to the service provider

Volume II

Add the following Transaction to Volume II 

Provide X-User Assertion

Use Case Roles

[[image:ucr.jpr|frame|center]

Actor

Actor 1

Role

Role of Actor 1

lather, rise and repeat for each actor

Referenced Standards

Normative -- required to use this profile

• OASIS http://www.oasis-open.org/committees/security/.
  • WSS Web Services Security V1.1 including errata
  • WSS SAML Web Services Security SAML Token Profile V1.1 including errata
  • SAMLCore SAML V2.0 Core standard

Informative -- assist with understanding or implementing this profile

• IHE Profiles
  • Personnel White Pages Profile
  • Enterprise User Authentication Profile
  • Basic Patient Privacy Consents Profile
• SAML V2.0 Standards http://www.oasis-open.org/committees/security/.
  • SAMLTechOvw SAML V2.0 Technical Overview (a work in progress currently at revision 10)
  • SAML Tutorial presentation by Eve Maler of Sun Microsystems
  • SAML Metadata Version 2.0
• WS-I
  • WS-I Conformance Claim
  • WS-I Basic Security Profile Version 1.1 (Doesn't use SAML 2.0)
  • WS-I Basic Profile Version 1.2 (Doesn't use SOAP 1.2)
• W3C
  • WS-Policy Version 1.2
  • SOAP Version 1.2
• ISO
  • ISO/TS 21091 Health informatics — Directory services for security, communications and identification of professionals and patients
  • ISO 17090 Health informatics - Digital Certificates in Healthcare
  • ISO/DTS 21298 Functional and Structural Roles from (work item in committee)
• CEN
  • CEN 13606-4 (makes normative ISO 21298 role vocabulary?)

Interaction Diagram

File:Int.jpg