Return to detail page at www.hitsp.org	HITSP/C19
	Prev  TOC  Next

---

2.0 Component Definition

2.1 Context Overview

HITSP defines Interoperability Specifications that specify a set of transactions, the content, and the representation of the content for the exchange of information within a defined context between a service consumer and a service provider. This loose coupling is one of the concepts behind a Services Oriented Architecture (SOA). In this type of architecture there is a need for the service provider to be able to obtain a trustable identity of the user that has initiated or triggered the transaction. This method of defining a set of claims about an identity is an assertion. In many of the HITSP transactions there is no direct user and the action is undertaken by an automated process. For this reason, this construct identifies the roles and behaviors of an entity. The service provider may be part of a different security domain, and thus not directly under the same security controls that have defined the method used to authenticate a human user. This user authentication and all of the identity management (provisioning, role engineering, attribute management, etc) are orthogonal to the assertion, although critical to its makeup.

This Component focuses on the concept of an assertion service participating in a transaction as the Service Provider interface(s). This service supports a variety of authentication mechanisms, and is the means by which other interface(s)s within HITSP Interoperability Specifications obtain an identity assertion.

The following are the requirements derived from the AHIC Use Cases for the authentication and assertion of users:

1. Entities are asserted to assure that the entity is the person or application that claims the identity.

In addition, the Entity Identity Assertion Component is meant to apply to the following scenarios as defined in the HITSP Interoperability Specifications:

2. User using a Document Registry or Document Repository where the Service Provider wants a user identity for additional detail in their audit log.

3. User using a Document Registry or Document Repository where the Service Provider wants to be assured that the user has been authenticated to a specific assurance level.

4. User using a Document Registry or Document Repository where the Service Provider wants to impose additional access controls.

5. User using a Document Registry or Document Repository is the consumer. The consumer is using an authorized PHR service which is handling the Document Consumer responsibilities. The Service Provider wants to restrict the information returned to those that have been released for consumer consumption (for example a lab result that regulations require the provider to discuss in person before releasing the information).

2.1.1 Component Constraints

Table 2-1 Component Constraints

2.1.2 Component Dependencies

Table 2-2 Component Dependencies

2.2 Rules for Implementing

For the purposes of this Component, pre- and post- conditions, as well as triggers and outputs, are also identified. A Unified Modeling Language (UML) sequence diagram is provided to show the high-level outline of how the Component works.

2.2.1 Data Mapping

Table 2-3 Data Mapping

2.2.2 Guidelines and Examples

This section provides additional guidelines and examples that support the underlying base or composite standards for this Component. It describes how these specifications differ from the underlying standards, and provides guidelines and examples for implementation.

See the following sections for additional information about this Component.

2.2.2.1 Pre-conditions

This section describes the necessary pre-conditions that must be in place prior to the onset of the workings of the Component. The pre-conditions are used to convey any conditions that must be true at the outset of a Component. They describe the context that must be established before the Component is executed. They are not however the triggers that initiate the Component. Where one or more pre-conditions are not met, the behavior of the Component should be considered uncertain.

Table 2-4 Pre-conditions

2.2.2.1.1 Process Triggers

This section describes the process triggers, including interface(s)s and/or processes, which are necessary to start the Component. They can invoke an automatic or manual process or result that in turn starts off the Component. A process trigger is not the same as a pre-condition that describes a context that needs to be in place at the start of the event.

Table 2-5 Process Triggers

2.2.2.2 Post-conditions

This section provides an overview of the post-conditions or results that must occur at the end of the Component in order for the Component to be deemed successfully completed. This includes any required outputs from the Component, or specific interface(s) states.

Table 2-6 Post-conditions

The following post-conditions are noted:

1. There may be an additional post-condition of the assertion being reformulated for application-specific usage. This is outside the scope of this Component as it is an implementation-specific detail.

2. There may be an additional post-condition of conveying authentication and/or assertion information. This is outside the scope of this Component as it is an implementation-specific detail.

2.2.2.2.1 Required Outputs

This section identifies the required outputs that must be produced at the end of the Component in order for the Component to be deemed successfully completed. This includes the format and usage of the required outputs.

Table 2-7 Required Outputs

In subsequent iterations of this Component, the HITSP Security, Privacy and Infrastructure Domain Technical Committee will define in more detail what specific data are available from this Component. This will include the definition of a minimum data set which needs to be recognized as the minimum data set for assertions.

2.2.2.3 Interfaces

This section describes the interfaces that should be integrated in order to meet the interoperability requirements for this Component. An interface represents an entity internal to a software application, which is engaged in one or more specific interactions to support a specific aspect of a real world information interchange (e.g., set of message exchanges). The table below lists the interfaces involved, the relevant definition of their roles, and an indication of their requirements for the Component.

Table 2-8 Interfaces

2.2.2.4 Interface Interactions

The following sections document the content of the Component and the basic process flows that are supported by the Component. It describes the underlying events that fulfill the Component, the sequence and timing of the events, and the specific interfaces involved. Process flow diagrams are provided to illustrate the process relationships.

Figure 2-1 Entity Identity Assertion Sequence Diagram

This process flow focuses on the provision of a SAML Identity Assertion, which represents a set of claims about an authenticated principal (entity, application, system) that is issued either by an Assertion Provider (represented in the above diagram as the Identity Provider interface) or by a Service Provider (defined in this diagram as the Service Provider Interface).

Within the Entity Identity Assertion process flow, the Service User (defined as an entity or principal) is asserted by an Identity Provider, which provides an assertion as outlined in the Provide Assertion interaction. The Provide Assertion interaction outlines how this Component provides a trustable user assertion from the Identity Provider to the Service User.

The Service User (representative of an entity or principal) then communicates with a Service Provider (defined in this diagram as the Service Provider Interface), conveying their identifier and authenticating assertions (represented in a SAML assertion). This is represented in the Convey Assertion interaction.

A Service User may invoke this Component by making a request to another entity within a HITSP Interoperability Specification, such as a laboratory or public health agency, which represents the trigger for the presentation of credentials for SAML assertion. Receipt of this assertion is the trigger for a possible additional scenario; the processing and verification of the assertion (captured in the Process Assertion and Verify Assertion interactions).

This Component, when completed, will constitute an auditable event. This Component does not specify how to reference the Identity Assertion in an audit message. This Component is designed to be agnostic to the mechanisms that provide the specific auditing event.

2.2.2.5 Web Services Flows

For authentications made through user assertion using Web Services, the following data flow applies (from the IHE Cross-Enterprise User Authentication (XUA) Supplement to the IHE-ITI-TF-2):

Figure 2-2 WS-Security Assertion Sequence Diagram

This is added as reference material for those implementations that are specific to Web Services. The same interactions related to assertion in Section 2.2.2.2 (Post-conditions) will apply.

2.3 Standards

2.3.1 Regulatory Guidance

Table 2-9 Regulatory Guidance

2.3.2 Selected Standards

Table 2-10 Selected Standards

2.3.3 Informative Reference Standards

Table 2-11 Informative Reference Standards

---

	Return to detail page at www.hitsp.org	HITSP/C19
	Prev  TOC  Next