9. XUA - Cross Enterprise User Assertion

Owner of this task

ViCarePlus HealthCare IT Services & Support

6559, SpringPath Lane, San Jose, CA, USA

Website: http://www.vicareplus.com

Email: services@vicareplus.com

Meaningful Use Requirement

Verify that a person or entity seeking access to electronic health information across a network is the one claimed and is authorized to access such information in accordance with the standard specified. Use of a cross-enterprise secure transaction that contains sufficient identity information such that the receiver can make access control decisions and produce detailed and accurate security audit trails (e.g., IHE Cross Enterprise User Assertion (XUA) with SAML identity assertions)

Cross-Enterprise User Authentication (XUA)

While participating in the HIE activities (eg:for document sharing), the users (on the EHR side) need to provide their identity to the HIE. XUA profile specifies the standards to accomplish this.

The XUA Profile provides a means to communicate claims about an authenticated principal (user, application, system...) in transactions that cross enterprise boundaries. Enterprises may choose to have their own user directory and their own unique method of authenticating. The user identity that is communicated in a cross-enterprise transaction needs to include enough information about the user authentication event, core attributes about the user, and the functionality being used.

SASL v2.0 Assertion, defined by the OASIS standards organization contains the user identity details. OASIS WS-Trust standard defines a Security Token Service (STS) that can bridge the enterprise authentication system and the security token.

The XUA profile

The XUA profile has three actors participating in three transactions. The following figure shows the actors directly involved in the XUA Profile and the transactions between them. Other actors and transactions that may be indirectly involved due to their participation in other grouped profiles are shown in italics. The “Authenticate User” transaction is outside the scope of this profile and may be filled through the use of EUA or some other enterprise class authentication. The “Request any service” transaction is outside the scope of this profile and represents an existing transaction that needs to convey user authentication information (i.e. XUA Assertion).

X-Assertion Provider: Provider the SAML assertion (which describes the user) to the X-Service User upon request. It contacts the Authentication provider to validate the user and collects the user attributes

X-Service User: requests and obtains an assertion from an authority (the X-Assertion Provider) and sends it to the X-Service Provider

X-Service Provider: receives the assertion from the X-Service User, parses and validates the assertion with a trusted authority (the X-Assertion Provider) and acts accordingly

XUA - Actors

Security Assertion Markup Language (SAML)

Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions).

SAML Assertion

   The SAML Assertion has some important qualities: 
      •  open standard 
      •  supports homogenous and heterogeneous environments 
      •  can carry multiple user authentication assertions, 
      •  identities are marked with the assurance level each provides 
      •  can carry additional attributes about the user such as email, role, address, preferences 
      •  the identity information can be a pseudonym when appropriate 
      •  the assertion content can be defined by the service that will consume them 

Pre-Generated Assertion

The case that is described might be considered a “pre- generated assertion” as the client application gets the user assertion before starting the original transaction. The case is represented here by a XDS PIX/PDQ Query that is using HL7. This second case is one where the X-Service User Actor knows that it must provide an Assertion in the transaction. The General Practitioner, Charley, is using an HL7 Query to find the Affinity Domain Patient Identity (See PIX for details on this transaction). Charley has authenticated to his enterprise authentication system (e.g. EUA). Charley is using an intelligent Actor that can generate the user assertion and embed it into the transaction. The Patient Identifier Cross-Reference Manager Actor may use this identity to determine the user’s permissions to access the data, and to record the retrieve (export) event. See Figure 6 for the transaction details. This configuration leverages the SAML v2.0 [SAMLprof] Assertion Query/Request Profile.

Scenario pre generated assertion

Post-Generated Assertion

The case that is described might be considered a “post-generated assertion” as the client application attempts the original transaction first and this initiates the creation/communications of the assertion. This configuration is represented here by an IHE Retrieve Information for Display (RID) transaction. There are other cases where this configuration is used. A healthcare provider, Alice, is seeing a patient and wants to examine the patient’s medical history. The patient’s clinical data has been made available in accordance with the IHE RID profile. The healthcare provider, Alice, has authenticated to her enterprise authentication system (e.g. EUA). Alice uses her browser to retrieve displayable summaries of lab results. The healthcare provider must supply an assured identity for herself to the RID Information Source Actor. The RID Information Source Actor may use this identity to determine the user’s permissions to access the data, and to record the retrieve (export) event. See Figure 5 for the transaction details. This configuration leverages the SAML v2.0 [SAMLprof] Web SSO and Enhanced Client/Proxy Profiles.Note at the present time the XDS Query and XDS Retrieve transactions are best implemented using the SAML 2.0 [SAMLprof] Enhanced Client/Proxy Profile. The benefit of this profile is that the XDS Consumer Actor takes an active part in the transaction and thus controls the process better.

Scenario post generated assertion

Task to be performed with respect to OpenEMR

1. Setting up Authentication provider & X-Assertion Provider

2.Authenticate user

  Before any HIE transactions, user needs to be authenticated by the authentication provider. 

3. Getting the assert token

  Getting the X-User identity from the X-Assertion Provider

4. Sending the SAML assert token to X-Service Provider [HIE]

5. Verification of SAML assert token when X-Service Provider [HIE] requests for the same

6. Processing the acknowledgement sent by the X-Service provider

7. Performing audit logging wherever appropriate

Note: All communications which involve assert message should take place via SAML .

Status

Not required for Certification. So this feature development is currently suspended.

Reference

Integrating XUA with an EHR - http://openmedsoftware.org/wiki/File:XUA_Visolve.pdf