View source for 9. XUA - Cross Enterprise User Assertion

== Owner of this task ==
[[File:ViCarePlus_Logo.png‎|link=http://www.vicareplus.com|OpenEMR and EHR Support]]

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'''
[[File:XUA_actor.png||600px]]

== 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'''
[[File:Pre_generated_assertion.png||600px]]

== 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'''
[[File:Post_generated_assertion.png||600px]]

== 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


[[Category:Certification]][[Category:Certification Stage I]]