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) provides a means to establish the user identity of an authenticated principal (user, application, system...) in transactions that cross enterprise boundaries. 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. The XUA Profile supports enterprises that have chosen to have their own user directory with their own unique method of authenticating the users, and others that may have chosen to use a third party to perform the authentication.

Issue Log

XUA001: In first year we are not required manditory communications of Attributes. This includes any form of functional or structural role. The main reason is the lack of a globally accepted vocabulary, mechanisms to rationalize with local RBAC infrastructures, and an unclear set of use-cases that can be used to properly architect. It is noted that an Affinity Domain can choose to add attributes.
XUA002: Support for XCA is out-of-scope. User using an Initiating Community-Gateway needs to provide a user assertion that can be utilized by the Receiving Community-Gateway. Where the Cross-Community-Gateway needs to act-on-behalf of the requester, this will require that the Assertions can be re-purposed (delegation) for the next Gateway or Reg
XUA003: Mentions of infrastructural failure is out of scope, as IHE only defines the interface.
XUA004: Break-glass is out of scope. E.g. 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. BPPC enforcement should be done on the edge system where current context can be applied to the BPPC policy and if the BPPC policy allows for break-glass this can be done on the edge system.

For further discussion and Close Issues See the discussion on the IHE Wiki http://wiki.ihe.net/index.php?title=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: a set of claims about an authenticated principal (user, application, system...) that is issued by a trusted identity provider
Principal: An end user, an application, a machine, or any other type of entity that may act as a requester in a transaction. A principal is typically represented in a transaction with a digital identity and the principal may have multiple valid digital identities to use with different transactions -- (modified from Source WS-Federation)
X-Assertion Provider: This is a SAML Identity Provider (IDP) or WS-Trust Security Token Service (STS), and is not further specified by IHE.

Volume I

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

The Cross-Enterprise User Assertion Profile (XUA) - provides a means to establish the user identity of an authenticated principal (user, application, system...) in transactions that cross enterprise boundaries. 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. The XUA Profile will support enterprises that have chosen to have their own user directory with their own unique method of authenticating the users, and others that may have chosen to use a third party to perform the authentication.

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) defines a set of trustable claims about an authenticated principal (user, application, system...) using a transactions that may cross enterprise boundaries. 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. The XUA Profile will support enterprises that have chosen to have their own user directory with their own unique method of authenticating the users, and others that may have chosen to use a third party.

Add the following section to Vol 1

Cross-Enterprise User Assertion (XUA) Integration Profile

The Cross-Enterprise User Assertion Profile (XUA) defines a set of trustable claims about an authenticated principal (user, application, system...) using a transactions that may cross enterprise boundaries. 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. The XUA Profile will support enterprises that have chosen to have their own user directory with their own unique method of authenticating the users, and others that may have chosen to use a third party.

There are transactions defined by IHE that cross enterprise boundaries. The existing IHE profiles for an authenticated user identity (EUA) will not function in cross-enterprise transactions. 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 type of requirement is the focus of the Identity Federation standards. Identity Federation has received much attention by the security and the platforms industry. Identity Federation is agnostic to the type of user directory, it allows for a centralized user directory, but also supports the more powerful federation of user directories. Identity Federation also supports many methods of user authentication (password, biometrics, smartcard) and can include details about the method(s) used.

The XUA Profile leverages Web-Services Security, SAML 2.0 Token Profile and the various profiles from W3C, OASIS, and WS-I to support identity federation. 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.

Use Cases

This profile will likely take two years. In the first year we will be focusing only on XDS.b Registry Stored Query and Retrieve Document Set 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; and they utilize modern Web-Services standards.

The XUA profile supports complex environments such as: where at least two different trust domains that are operating under different technology, procedures, role-models, etc. They are cooperating in the XDS Affinity domain under an overarching trust relationship policy that indicates that these differences can be rationalized. The XDS transactions are transferring access control from one entity to another. For example, using XDS to exchange data between a single doctor practice, and large multi-site hospital. It is not likely that they will all agree to the same access control model. It is not necessary to have the same access control across these entities, but it is reasonable that at the policy level they will agree to a set of processing rules. This illustrates an important fact that the XUA is useful for security audit logging, but is to a lesser extent useful for access controls.

The following is an inclusive list of use-cases that have been proposed for XUA. In the first year some of these use-cases will not be supported due to lack of standards or sufficient guidance on the proper solution.

Country that provisions users into a single assigning authority domain (e.g., Germany) and handles all user authentication requests
- Support for centralized user directories
Region that knits together many competing hospitals and clinics where each hospital/clinic manages their own users.
- Support for distributed user directories
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 non-healthcare specific user directories
Hospital issues identity badges with picture and name printed, RFID for building access, and smart-card for strong authentication
- Support for claims about the method used to authenticate the user (e.g. strong authentication methods such as smart-cards)
Small clinic in a rural setting supports a dozen users.
- Support for small scale systems (e.g., user at a kiosk, system using simple passwords)
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
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
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 requester 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.
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.
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 to record the identity and role in the audit log.
- Support inclusion of functional roles as named vocabulary
- The Role of the user as the data subject (patient)
Service provider wants to enforce some form of access controls based on the user identity and/or functional role.
- Support for the service provider to augment access controls based on some non-specified rules that are applied to the user and/or functional role
Access of a document by an individual that can’t be identified because the Assertion Provider is not accessible

XUA Development

The vast majority of the use-case (items 1-11) rely on the establishment of an authenticated identity assertion which a SAML 2.0 Identity Assertion can provide. This is a mature standard produced by OASIS. For our first year we have focused on XDS.b Document Consumer two transactions that utilize Web-Services. XUA specifies 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 Token containing the identity Assertion. As with any IHE profile, the applications are not forbidden to use other methods of providing the user (principal) identity, providing that interoperability has been assured through some policy.

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

The method of authenticating the user (principal) and the method that the XDS-Consumer uses to get the SAML 2.0 Identity Assertion is outside the scope of this profile.

There are user (principal) attributes that appear to be needed in the use-cases: Doctor, Patient, Guardian, Emergency-Access. The SAML 2.0 Identity Assertion can contain attributes about the user (principal). 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.b Document Consumer to determine the contents of the SAML 2.0 Assertion is outside the scope of this profile. This can be accomplished using the SAML Metadata and WS-Policy.

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

Actors/Transaction

Figure X.1-1 shows the actors directly (Bold and Solid Boxes) involved in the XUA Integration Profile and the relevant transactions between them (Bold and Solid Line). The diagram shows ancillary actors (Dashed and Grey Boxes) that are not profiled but include interactions (Dashed and Grey Boxes). The two XDS.b Document Consumer transactions supported are shown as the dashed line between the X-Service User and the X-Service Provider.

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

Grouping

please add text that explains how this profile modifies the XDS transactions.

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.

In this figure the dark lines represent the X-User Assertion transaction. The thin lines represent other standards based transactions that may be used. WS session A and B show an example where one X-User Assertion is used to cover two Web-Services transactions. Where WS Session C is using a different X-User Assertion. This may be due to a different user, timeout of the previous X-User Assertion, or some other reason.

Actor Definitions

Add the following Actor Summary Definitions in Appendix A

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 user to the service provider

Volume II

Add the following Transaction to Volume II

Provide X-User Assertion

This section corresponds to Transaction ITI-XXX of the IHE IT Infrastructure Technical Framework.

Scope

Transaction ITI-XXX is used by the X-Service User to pass a trustable identity assertion to the X-Service Provider. The X-Service User and X-Service Provider use the 'X-Assertion Provider' as the trusted third party issuer of the trustable identity assertion.

Use Case Roles

Actor: X-Service User
Role: User of a transaction that requires a Cross-Enterprise User Assertion
Actor: X-Service Provider
Role: Service provider on a transaction that requires a Cross-Enterprise User Assertion
Actor: X-Assertion Provider
Role: Source of Cross-Enterprise User Assertions

Referenced Standards

Normative -- required to use this profile

OASIS http://www.oasis-open.org/committees/security/.
- SAMLCore SAML V2.0 Core standard
- WS-Trust OASIS Committee Draft, "WS-Trust 1.3", September 2006
- WS-SecureConversation OASIS Committee Draft, “WS-SecureConversation 1.3", September 2006
- WSS10 OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)", March 2004.
- WSS11 OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.1 (WS-Security 2004)", February 2006.
- WSS:SAMLTokenProfile1.0 OASIS Standard, “Web Services Security: SAML Token Profile”, December 2004
- WSS:SAMLTokenProfile1.1 OASIS Standard, “Web Services Security: SAML Token Profile 1.1”, February 2006

Informative -- assist with understanding or implementing this profile

IHE Profiles
- Personnel White Pages Profile
- Enterprise User Authentication Profile
- Basic Patient Privacy Consents Profile
OASIS-OPEN
- 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
- SOAP W3C Note, "SOAP: Simple Object Access Protocol 1.1", 08 May 2000.
- SOAP 1.2 W3C Recommendation, "SOAP 1.2 Part 1: Messaging Framework", 24 June 2003.
- SOAPNorm W3C Working Group Note, "SOAP Version 1.2 Message Normalization”, 8 October 2003.
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

X-User Assertion Messages

X-User Assertion

The X-User Assertion is profiled to assure interoperability between a X-Service User and an X-Service Provider that need an Assertion about the entity requesting the service. There are many ways to provide an Assertion that are all acceptable and may be used by parties that have agreed to their use.

The X-User Assertion transaction shall be used when there is no other agreed upon policy. It is expected that in the future WS-SecurityPolicy published by the X-Service Provider will be sufficient to ensure interoperability.

The X-User Assertion is specified for the XDS.b Registry Stored Query and XDS.b Retrieve Document Set transactions. Use beyond these two transactions is possible but not specified.

Trigger

Configuration of the X-Service Provider and X-Service User indicates when the X-User Assertion transaction is necessary.

Message Semantics

The XDS Transactions already require ATNA and thus TLS Mutual-Authentication, Integrity, and Confidentiality.
The Web-Services Transaction shall include the OASIS Web Services Security (WSS) Header.
The Web-Services Security Header shall include a SAML 2.0 Assertion as the security token.
The SAML 2.0 Assertion is profiled as follows:
- The Assertion shall contain a Subject profiled as follows:
  - The Subject contains the invocation identity. The invocation identity is the logical identity of the entity performing the original service request (person, application, etc.) and remains unchanged through operations acting on the assertion (e.g. proxying). The Subject if profiled as:
  - XUA and XCA shall support bearer assertions
  - XUA may support holder-of-key (Not sure how this works in XCA environments)
- The SAML Assertion Conditions are profiled as:
  - NotBefore shall be populated with the issue instant of the Assertion
  - NotOnOrAfter is not specified by XUA because reasonable time limits are not clear at the IHE Profile level. The Expiration shall be configurable on an Affinity Domain and/or System level.
  - The assertion shall contain an AudienceRestriction containing an Audience whose value is a URI identifying the relying party (e.g. XDS Registry, XDS Repository). It may also contain an Audience whose value is a URI identifying the Affinity Domain.
  - The Assertion may containProxyRestriction and OneTimeUser conditions but XUA actors may ignore these conditions.
- The Assertion shall contain a AuthnStatement profiled as follows:
  - The Statement shall specify the AuthnContextClassRef or AuthnContextDeclRef
  - The Affinity Domain will provide the list of valid authentication context URNs
- The Assertion may contain other statements (e.g. Attributes)
- The Assertion shall be signed by the IdP
- The Assertion shall be used in ATNA Audit Messages

Notes:

The interface between the X-Service User and the IdP is not specified by XUA. This interface needs to protect against risks (e.g. exposure of the SAML Token to interception for malicious use)

Expected Actions

The X-Service Provider is expected to process the Web-Services Security header in accordance to the WSS, WS-Trust, and SAML 2.0 processing rules.
The X-Service Provider may use standards transactions to communicate with the X-Assertion Provider (e.g. WS-Trust, SAML Protocol)
The X-Service Provider shall utilize the identity in any appropriate ATNA audit log messages that result from the transaction (success/failure).
- need to provide ATNA encoding rules
The X-Service Provider may utilize the identity in access control decisions. Appropriate error messages, not defined here, shall be returned.
The X-Service Provider may ignore any other statements (e.g. Attributes)
The X-Service Provider may ignore the one-time-use-condition
The X-Service Provider may treat holder-of-key as a bearer token
The X-Service Provider may have a configurable list of authentication class references