Cross-Enterprise User Assertion (XUA)

From IHE Wiki
Jump to navigation Jump to search


Summary

Cross-Enterprise User Assertion Profile (XUA) - provides a means to communicate claims about the 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 principal in a way that enables the receiver to make access decisions and generate the 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, as well as others that may have chosen to use a third party to perform the authentication. The XUA profile carries a readable and verifiable claim of the user identity, authentication method, and as needed their roles, purpose of use, and consent.

Benefits

Assistance to sites in implementing security and confidentiality policies There are transactions defined by IHE that cross enterprise boundaries and are web-services based on ITI TF-2:Appendix V. The existing IHE profiles for an authenticated user identity (IHE Enterprise User Authentication Profile [EUA]) are not intended to 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 (IHE Personnel White Pages [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.

Details

The vast majority of the use-cases rely on claims about an authenticated identity, which a SAML 2.0 Identity Assertion can provide. This is a mature standard produced by OASIS. XUA Profile is focused on Web-Services transactions that follow ITI TF-2:Appendix V. XUA specifies that when a Cross-Enterprise User Assertion is needed, 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 principal (user) identity, providing that interoperability has been assured through some policy.

A very clear need on all the use-cases is the recording of the user identity in any security audit logs. The XUA profile does not define these auditable events. The need to record a security audit event is driven by the grouped transactions (e.g., XDS.b Registry Stored Query, and XDS.b Retrieve Document Set). XUA does specify how to reference the Identity Assertion in an ATNA Audit Message.

The method of authenticating the principal (user) and the method that the X-Service User Actor (e.g. XDS.b Document Consumer) uses to get the Identity Assertion are outside the scope of this profile. There are principal (user) attributes that appear to be needed in the use-cases: Doctor, Patient, Guardian, Emergency-Access. The Identity Assertion can contain attributes about the principal (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 X-Service User (e.g. XDS.b Document Consumer) Actor to determine the contents of the Identity Assertion is outside the scope of this profile. This might 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.

Systems Affected

Systems involved in this profile are:

  • Any application or service that utilizes Web-Services transactions.

Actors & Transactions:

Figure 13.4-1 Cross-Enterprise User Assertion Actor Diagram

Options

The XUA profile includes three options that enable the XUA SAML Assertion to carry the

  • Subject Role -- Enables the listing of appropriate security roles (Functional or Structural) that the user holds. The list should be targeted as appropriate for the service request. The role codes found in SNOMEDCT, ISO 21298, or ASTM E1986.
  • Purpose Of Use -- Enables the identification of the intended Purpose Of Use that the user has regarding the service request. This should be the inclusive list of purpose of use values, and the use of any data communicated must be constrained to those purposes requested. The codes found in ISO 14265, or OASIS-XSPA
  • Authorization Consent -- There are transactions where the requester of the transaction knows of specific Consent/Authorization evidence that would enable that transaction. The identification could be used by the relying party Access Control engine as a hint. The relying part is not compelled to agree. The value would contain either an identifier of a Patient Privacy Policy Identifier (of the consent Document), or a Patient Privacy Policy

Identifiers.

Specification

Profile Status: Final Text

Documents: IHE IT Infrastructure Technical Framework Version 5 or later

  • Vol. 1 - Section 13
  • Vol. 2(b) - Sections 3.40

Underlying Standards:

ITI XUA Extension

See Also

This profile supports the security/privacy model discussed in IHE Security and Privacy for HIE white paper.

Related Profiles

2010 - ITI XUA Extension supplement is extending XUA


This page is based on the Profile Template

Current: IT Infrastructure Technical Framework.

There are two articles on this topic. First there is the Cross-Enterprise User Assertion - Discussion. The profile document is being developed at Cross-Enterprise User Assertion Profile

Retrieved from "http://wiki.ihe.net/index.php?title=Cross-Enterprise_User_Assertion_(XUA)&oldid=102977"