Revision as of 18:24, 8 December 2015

Secure Retrieve (SeR)

Introduction

This supplement defines new functionalities for an XDS environment with a unique and centralized Access Control system. As a Trial Implementation Supplement, this profile is limited to those deployment models and their policies where a central authorization authority can make complete and definitive decisions, yet support federated identity/authentication. These use-cases specifically mean that neither XDS Document Source nor XDS Document Repository Actors need to have any more fine-grain policies to enforce. The supplement describes how to create a “system of trust” between the actor that can perform Access Decisions (on behalf of Consent Docs, Policies and Creation/Access/Disclosure rules) and XDS Actors that actually store clinical data and documents. Access decisions are often based on metadata (e.g., document types, practiceSetting); therefore the source of truth for metadata (i.e., the XDS Document Registry) is the best place to make the decisions. With the objective to keep the data close to the decision point, the XDS Document Registry in many implementations, is a good candidate to perform access control decisions (Authorization Decisions Manager or Policy Decision Point). In a typical XDS environment, there are many XDS Document Repositories that store documents. These systems are not aware of Consent Documents published by patients, and cannot apply Access/Creation/Disclosure Policies to requests for Document retrieval; then the replication of Access Control functionalities is unfeasible and/or too expensive (due to integration burdens and total cost of ownership). The objective of the Secure Retrieve Profile is the definition of a mechanism to convey Authorization Decisions between XDS Actors, attesting that the reliable Policy Decision Point (PDP) has already made an access decision. The starting requirements/constraints upon which this profile is developed are described below:

A unique PDP performs access decision for all XDS Document Consumer and all XDS Document Repositories involved in the Affinity Domain.

XDS Document Repositories cannot manage the whole set of information needed to perform access decisions (XDS Document Repositories are not required to store metadata. If the Repository stores metadata, the metadata might be insufficient to perform an access decision).

The XDS infrastructure is not fully federated; a clear separation of duties and responsibilities between PDP and XDS Document Repositories is needed (Repositories store clinical documents; PDP evaluates access rights to those contents).

The XDS Document Repositories must enforce access decision made by the Policy Decision Point.

A technical pattern that reduces behavioral and transactional changes for the Consumer side is clearly preferred (lower costs for deployment and for security reasons).

This supplement is a standalone profile because it defines a flexible pattern that could be used by any Service Provider that queries for Authorization Decisions already granted by a trusted Authorization Decisions Manager (or PDP). However, the focus is to add Access Control functionalities to the XDS environment. This profile introduces two new actors (Authorization Decisions Manager and Authorization Decisions Verifier) and one new transaction (Authorization Decisions Query). This profile does not describe how Authorization Decisions are performed. However, this profile relies on XACM-SAML framework, so these standards could be good candidates to implement Authorization Requests. This profile describes how a Service Provider (e.g., Document Repository) can discover the existence of Authorization Decisions granted to an entity and for specific documents.

Actors and Transactions

Actors

Authorization Decisions Manager

The Authorization Decisions Manager is responsible for the management of access control decisions in the entire XDS domain. From the Access Control point of view, this actor is the unique Policy Decision Point (PDP) of the entire domain for all documents because it may decide on the outcome of an incoming authorization request in order to provide access to specific resources (documents). The Authorization Decisions Manager completes the Authorization Decision creating and storing a security token. This security token does not need to be exposed to other systems, and it certifies the decision made. This actor could implement additional Access Control functionalities required in the specific implementation scenario. (Refer to the White Paper IHE ITI Access Control White Paper for further information about PDP and Access Control Systems).

Authorization Decisions Verifier

The Authorization Decisions Verifier is the actor that verifies if the Requester Entity is authorized to access specific resources by querying the Authorization Decisions Verifier. This actor enforces the Access Decision made by the trusted Policy Decision Point, so it acts as a Policy Enforcement Point (PEP). This actor enables the secure exposure of documents, allowing access only to Requester Entities previously authorized by the Policy Decision Point. The Requester Entities (XDS Document Consumer) convey at least the following information to the Authorization Decisions Verifier:

Requester Entity that obtains authorization (e.g., using an identity assertion)
The unique ID of the document that can be accessed (within the Retrieve Document Set-b Request)

(Refer to the White Paper IHE ITI Access Control White Paper for further information about PEP and Access Control Systems).

Transactions

Authorization Decisions Query

This transaction is used by the Authorization Decisions Verifier to query for authorization decisions, granted and managed by the Authorization Decisions Manager. These authorization decisions are created for an entity that is authorized to disclose specific documents. The Authorization Decisions Verifier asks for authorizations based on: the Requester Entity and the requested documents identifiers.

Relevant standards:

OASIS SOAP v1.2
OASIS Security Assertion Markup Language (SAML) v2.0
OASIS eXtensible Access Control Markup Language (XACML) v2.0
OASIS Multiple resource profile of XACML v2.0
OASIS SAML 2.0 profile for XACML v2.0
OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of SAML v2.0 for Healthcare Version 2.0 (not normative)

@@ Line 24: / Line 24: @@
 This profile does not describe how Authorization Decisions are performed. However, this profile relies on XACM-SAML framework, so these standards could be good candidates to implement Authorization Requests.
 This profile describes how a Service Provider (e.g., Document Repository) can discover the existence of Authorization Decisions granted to an entity and for specific documents.
-== Use-Case of Reference: Environment with a centralized Access Decision Manager Use Case Description ==
-The XDS Document Repositories are all in the same XDS Affinity Domain, but are unable to perform access decisions. When an entity tries to retrieve some documents from an XDS Repository the XDS Document Repository lacks of the information needed to make an access control decision. The Authorization Decisions Manager can make the decision at the time of the query to the XDS Registry. This decision is enforced by the XDS Document Repository grouped with an Authorization Decisions Verifier.
-For example:
-Mr. White comes to his GP, Dr. Brown, to show him a Laboratory Report. This Laboratory Report is shared in a XDS infrastructure. Using his EHR, Dr. Brown queries for Mr. White’s Laboratory Reports shared in the XDS infrastructure. The Query Response returns some DocumentEntries to the XDS Document Consumer. Each XDSDocumentEntry in the response is authorized for the retrieval. Dr. Brown uses his XDS Document Consumer to retrieve these documents. XDS Document Repository verifies the authorization for the Requester Entity for each document requested before providing documents.
-No other access control decisions are needed at this level.
-Each Authorization Decision has a time slot of validity. Dr. Brown can retrieve documents until the Authorization expires. The Repository discloses only documents requested and authorized.
-There are conditions where XDS Document Repository might not be providing documents:
-*The Requester Entity does not have authorization according to the Authorization Decisions Query
-*The authorization was granted too long ago and the Authorization Decision is expired
-The user attempting to retrieve from the XDS Document Repository is different from the user that was authorized (there is a mismatch between the user that performs the retrieve and the user that queries for documents).
 =Actors and Transactions=

Difference between revisions of "Secure Retrieve"