1

IHE ITI White Paper on Access Control

WP Review Cycle 1

Chapter 4: Actors and Transactions

Chapter 6: Implementation Issues

Dr. Jörg Caumanns, Raik Kuhlisch, Olaf RodeBerlin, 31.03.09

2

Objective of this TCon

- step through chapter 4 and consolidate organization

- discuss the recommendations for IHE actions

- schedule until May f2f

3

Page Count

Access Control in Healthcare 3.0 pages

Fundamentals of Access Control 10.0 pages (can be reduced by 1-2)

Policies and Attributes 16.0 pages (can be reduced by 2-3)

Actors and Transactions 22.0 pages (can be reduced by 2-4)

Examples 8.0 pages

Implementation Issues 8.0 pages (redundancies with 3 and 4)

Annex (glossary, standards, ..) 3.0 pages

70.0 pages (could be reduced to 60-65)

1 2 3 4 5 6 A

4

Status

Chapter 1 finalized, minor open issues

Chapter 2 finalized, minor open issues

Chapter 3 1st draft, open issues from February TCon

Chapter 4 1st draft, core discussed at last TCon

Chapter 5 subject to next TCon

Chapter 6 1st outline and fragments

1 2 3 4 5 6 A

5

State to reach before May f2f

Chapter 1: no severe open issues; will be moved forward to the next phase

Chapter 2: no severe open issues; will be moved forward to the next phase

Chapter 3: no severe open issues; will be moved forward to the next phase

Chapter 4: no severe open issues; will be moved forward to the next phase

Chapter 5: open issues on examples identified; will be discussed at f2f

Chapter 6: open issues on standards/profiles identified; will be discussed at f2f

March 31st: 52/70 pages written

April 24th : 70/70 pages written

6

Chapter 4: Actors and Transactions [~20-24 pages]

Intro and Sample Use Case [1.5 pages]

Methodology Overview [0.5 pages] -> should be 1.0

Step 1: Policy and Attributes [1.0 pages]

Step 2: Attribute-Domain Mapping [2.0 pages]

Step 3: Default Flow [5.0 pages]

Step 4: Adaptation [5.0 pages]

Step 5: Deployment [1.0 pages]

Sample Environments [2.5 pages]

Actors and Transactions [4.0 pages]

7

Open Issue from last TCon: Diagram Syntax

8

UML Collaboration Diagram

9

UML Sequence Diagram

10

UML Activity Diagram

11

Sample Use Case: 1 Storyboard, multiple environments

In a metropolitan area several hospitals set up a network for the exchange of medical patient data. Because of the high density of hospitals, the medical specialization of many of these hospitals, and a high degree of transparency with respect to treatment-specific quality parameters it has been observed that many patients visit different hospitals for different purposes and diseases. During anamnesis physicians often get aware of former treatment at other hospitals and the existence of diagnostic data that might be useful for consideration in order to evaluate the severity of ongoing processes and to verify a suspected diagnosis.

To face this situation a dedicated application is designed on top of the hospital network that enables physicians to easily access historical data from other hospitals that might be relevant for recent diagnosis (e. g. lab data, radiologic data). An access to this data is only permitted after the patient has consented:

• what kind of data might be accessed• which organizations might access this data• which roles are authorized to access this data• for what purpose the data might be accessed

12

Methodology

1. Design a policy profile and identify the attributes needed to instantiate the profile (see section 3 and section 4.3)

2. Identify the attribute sources and domains where these attribute can be made available (see section 4.4)

3. Define the default flow of control among the client-side and resource-side ACS (see section 4.5)

4. Optimize the flow of control with respect to the prioritized requirements (see sections 4.6 and 4.8)

5. Deploy the (logical) domains onto physical nodes (see sections 4.7 and 4.8)

6. Map the ACS building blocks and the messages among them onto actors and transactions (see section 4.9 and 6)

13

Step 1

policy instance

role-ID

org-ID

purpose-ID

patient-IDres.type-ID

policy decisionpolicy activation

lab data

physician

treatment

clinic A

patient attribute

subject attribute

context attribute

subject attribute

resource attributeresource ID my data

resource attribute

App-IDcontext attr.

historical DB

14

Context DomainSubject Domain

Patient Domain

Resource Domain

patient privacy policy (consent)

org. security policy

resource

Application Domain

application security policy

org. security policy

STS

STS

STS

STS

STS

request initiator

Trust

Step 2

patient ID

organization ID

subject ID

purpose ID

resource ID

subject role ID

resource type

organization ID

application id

application ID

Patient Privacy Policy:

org: Clinic A

role: physician

purpose: treatment

kind-of: lab data

subject role ID

15

Step 3a

Context Domain

STS

Subject Domain

purpose ID

context activationIdentity Prv.

consumer

subject roleSTS

subject ID org ID

subject role

org ID

XUA

app ID

subject ID

patient ID

organization ID

subject ID

subject role ID

role activation....

16

Step 3b

Patient Domain Resource Domain

patient privacy policy

resource IDpolicy activation

PEP / PDP

resource

resource type

patient ID

purpose ID

patient ID

subject role

org IDXUA

app ID

query for

app ID

request initiator

17

Context Domain

STS

Subject Domain

purpose ID

role activation

Identity Prv.

consumer

subject role

STS

org ID

subject role

org ID

XUA

app ID

subject IDpatient ID

subject ID

subject role

org ID

subject ID

STS

Patient Domain Resource Domain

patient privacy policy

resource IDpolicy activation

PEP / PDP

resource

resource type

patient ID

app ID

XUA

purpose ID

patient ID

app ID

Step 3

18

Context Domain

consumer

STS

Patient Domain

Resource Domain

patient privacy policy

policy activation

PEP / PDP

resource

Context Domain

consumer

STS

Patient Domain

Resource Domain

patient privacy policy

policy activation

PEP / PDP

resource

STS

Context Domain

consumer

STS

Patient Domain

Resource Domain

patient privacy policy

policy activation

PEP / PDP

resource

STS

policy ID

STS

policy repository

policy

policy

policy

Policy Pull Policy Push Policy Cache

19

Sample Environments (1/2)

Thin Client

Only web browsers are to be used as clients. Access control is implemented by the web portal that schedules queries and other requests to the respective databases at the participating hospitals.

Affinity Domain

The hospital network is set up as a XDS affinity domain with a central registry and distributed repositories within the hospitals. Queries for patient historical data are based on the IHE ITI-016 Query Registry transaction. The registry’s response only contains references to documents that match the patient’s privacy consent. Data itself is retrieved using the IHE ITI-017 Retrieve Document transaction. Again the restrictions of the patient’s consent have to be considered. For reasons of efficiency the policy should not be evaluated twice (once for each transaction) for retrieving a single document.

20

Sample Environments (2/2)

Integration of an existing repository

The hospital network is set up as sketched in 4.8.2. One of the participating hospitals uses an XDS repository implementation where the vendor is unable to integrate an ACS.

Application Service Integration

The historical database application is implemented as a web service that encapsulates the XDS affinity domain of the hospital network.

Multiple Affinity Domains

The hospital network is set up from multiple affinity domains which each consisting of a registry and a repository.

21

STS

X-Service User and ST provider actors are abstract superactors from which other actors can be derived that require a trusted encoding of their issued claims (comparable to the publisher and subscriber actors).

Other Actor Other ActorOther Actor

X-Service User ST Providerget X-Assertion

STS WrapperST Verifier

safeguardclaimverify claim

Trust

X-Service Provider

verify claim

provide X-Assertion

22

STS

Recommendation: IHE should define a framework for the definition of interoperable “get X-Assertion” and “provide X-assertion” transactions. This framework should consider two different levels of trust:

• direct trust (X-Service User consumes X-Assertion) and • brokered trust (X-Service User as intermediary between X-Service Provider

and ST Provider).

Other Actor Other ActorOther Actor

X-Service User ST Providerget X-Assertion

STS WrapperST Verifier

safeguardclaimverify claim

Trust

X-Service Provider

verify claim

provide X-Assertion

23

Attribute Provider

Recommendation: IHE should define a PIP as an instance of the STS-framework (see 4.9.1) for querying for attributes about an otherwise authenticated subject.

The respective actors and transactions are needed for infrastructures where subject authentication is performed within a domain that does not maintain role and organization membership information about the authenticated subject. E. g. if a health professional card is used, authentication is performed within a central subject domain (e. g. a nationwide PKI) while most of the subject’s attributes are managed with the enterprises subject domain (e. g. enterprise HR services).

24

Policy Activation

subject

purpose of use

activated roles...

policy

patient

assignment claim(scenario-policy)

policy-ID

The assignment of a policy to an access request must be verifiable for the PDP. The assignment is as trustworthy as the service that claims to have done this assignment by activating the referenced policy.

Two transactions are required to implement all three policy activation patterns:

1. activation/retrieval of a policy for a certain scenario

- response includes just the policy (policy pull pattern)

- response includes just the assignment claim (policy cache pattern)

- response includes assignment claim and policy (policy push pattern)

2. retrieval of a policy for a given policy-ID (policy cache pattern)

25

Policy Activation

As assignment claims must be authentic the issuing actor should be derived from the previously defined “ST provider” actor. Depending on the activation pattern the policy enforcing PDP and the ACS of the context side business service consumer take different roles:

Pattern Policy Activator Policy enforcing PDP Context domain ACS

Policy pull ST Provider X-Service User as X-Assertion Consumer

(not involved)

Policy push ST Provider X-Service Provider X-Service User as X-Assertion Broker (claim)

Policy cache ST Provider X-Service Provider (claim) and X-Service User (policy) as X-Assertion Consumer

X-Service User as X-Assertion Broker (claim)

Recommendation: IHE should provide a profile consisting of an policy activator actor (derived from the ST Provider superactor, focused on brokered trust scenarios) and a policy registry (derived from the ST Provider superactor, focused on direct trust scenarios) with transactions for policy activation (claim retrieval) and policy retrieval.

Recommendation: IHE should provide a profile consisting of an policy activator actor (derived from the ST Provider superactor, focused on brokered trust scenarios) and a policy registry (derived from the ST Provider superactor, focused on direct trust scenarios) with transactions for policy activation (claim retrieval) and policy retrieval.

26

PEP/PDP ensemble

There is no need for a dedicated profile, because all transactions are already covered by the other recommended profiles.

The only exception is PEP-PDP communication (XACML within SAML authorization decision stmt), which is an interoperability issue if PEP and PDP are distributed among different domains.

Recommendation: PEP/PDP should not be a profile in the 2009/2010 cycle. Instead the WP should be adapted to the other transactions recommended for profiling work in this paper after they passed their first connect-a-thon.

27

Identified minor Issues

Wording: “consumer”, “initiator”, “client”, ...

Wording: “enforcing policy decision” instead of “enforcing policy”

Wording: “pattern” vs. “variants” in section 4.6ff

28

Schedule (April 2009)

Monday Tuesday Wednesday

Thursday Friday Saturday Sunday

30 31 1 2 3 4 5

6 7 8 9 10 11 12

13 14 15

epSOS

16

epSOS

17

epSOS

18 19

20 21

epSOS

22

epSOS

23

epSOS

24 25 26

27 28 29 30 1 2 3

Chapter 5 (Examples)Chapter 5 (Examples)

Chapter 3-6 (Open Issues)Chapter 3-6 (Open Issues)