Cross-Enterprise User Assertion (XUA)
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.
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.
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 involved in this profile are:
- Any application or service that utilizes Web-Services transactions.
Actors & Transactions:
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
Profile Status: Final Text
- Vol. 1 - Section 13 - Cross-Enterprise User Assertion
- Vol. 2b - Sections 3.40 - Provide X User Assertion
- 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
This profile supports the security/privacy model discussed in IHE Security and Privacy for HIE white paper.
- Consistent Time [CT] < supports XUA in some fashion >
This page is based on the Profile Template
Current: IT Infrastructure Technical Framework.