1

IHE ITI White Paper on Access Control

WP Review Cycle 1

Chapter 1-2: Introduction and State of the Art

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

2

Editing Team

Authors: Raik Kuhlisch, Jörg Caumanns // Fraunhofer ISSTOliver Pfaff, Markus Franke // Siemens IT Solutions

// and Services Christof Strack, Heiko Lemke // SUN Microsystems

Supervisior: Rob Horn // Agfa Healthcare

Editorial Team: John Moehrke // GE HealthcareLynn Felhofer

Manuel Metz // GIP-DMP

3

Objective of this TeCon

- step through chapter 1-2 and consolidate core statements

- fine grained scoping of the WP boundaries (ins and outs)

- agree on the outline of chapter 3

4

Comment on the Scope and Direction of the WP

• Is this solely to provide direction to architects and implementers or will this provide direction for new profiles?

• Where’s the interoperability implication?• AC cannot be encapsulated with a single actor • consumers and providers of protected resources can only be interoperable if

their respective access control subsystems are interoperable, too

5

Chapter 1: Organization

1. Access Control in Healthcare• [Intro] [0.7 pages]• Access Control Scenarios [1.0 pages]• Objective and Outline [1.0 pages]

-------------2.7 pages

• Is the organization of chapter 1 appropriate?

6

Chapter 1: Intro

• Should a sentence on proactive measures (authorization) vs. reactive measures (audit trail) be added

• should this be discussed with more detail in another chapter?

• Scope: “This white paper points out how access control services should be integrated into healthcare IT infrastructures and how IHE can be used to support such policy-aware healthcare solutions.”

• does everybody agree on this?

• Patient Safety: “A dedicated focus will be on opportunities for preserving patient safety by keeping data accessible even in cases where the security subsystem is partly or totally unavailable.”

• sufficient?

7

Chapter 1.1: Access Control Scenarios

Motivation: Give an impression on how AC is (should be) used in healthcare

Is any important scenario missing?• Research?• Public Health?• Reimbursement?• Managed Care (health insurance)?• Quality Reports?

8

Chapter 1.2: Assumptions

• It is assumed that the design of the overall healthcare data exchange infrastructure is oriented towards the principles of a service-oriented architecture (SOA). It is further more assumed that a dedicated security architecture is set up which provides a circle-of-trust among the security and business services which are deployed among independent affinity domains.

9

Chapter 1.2: Focus

• The focus is mainly on issues that relate to the IT architecture and the flow of messages that are required for a distributed access control scenario. Therefore this paper will deal with the problems of

• how to apply established principles of secure design and SOA security on the design of access control systems,

• how to model an access control solution in a way that is well suited for reasoning and evaluation, and

• how to deploy an access control solution using well understood patterns and interoperable system components.

10

Chapter 1.2: Intended Audience

...the primarly intended audience are system architects and developers who are involved in the planning, design, and realization of regional healthcare networks and comparable infrastructures where the secure exchange of patient related data among enterprises is an issue

11

Chapter 2: State of the Art

• 2.1 State of the Art [4.0 pages]• [Intro] [0.2 pages]• Principles of Secure Design [1.6 pages]• Common AC Models [1.2 pages]• Policy Based AC [1.0 pages]

• 2.2 SOA Security Principles [1.5 pages]

• 2.3 Access Control System [4.7 pages]• [Intro] [0.7 pages]• Building Blocks [1.0 pages]• Access Control Domains [1.3 pages]• Federated Healthcare Environm. [0.7 pages]• IHE Profiles [1.0 pages]

12

2.1.1 Principles of Secure Design

• Principles considered:• Economy of Mechanism Complete Mediation• Open Design Least-Common Mechanism• Fail-Safe Defaults Separation of Privilege• Least Privileges Psychological Acceptability• Reluctance to Trust Privacy Consideration• Isolation

• Is this selection OK?

• Consideration: Add an appendix on how these principles can be realized using the concepts/patterns/guidelines provides in the white paper

13

Resource Access Policy:Who is allowed to access my EHRfor the given purpose/context?

ResourceBehaviour Policy:

How may authorizedsubjects work with my

EHR?

EHR Definition

Privacy Consent National Law

Agr

eem

ent

Con

figur

atio

n

Authorization Scope, Procedure, ...

Regulations

Access Control Paradigm: Input for the Discussion ...

14

2.1.2 Common AC Models

Considered Models• Discretionary Access Control• Mandatory Access Control (Bell-LaPadula)• Role-Based Access Control

Other Models? • Attribute-Based Access Control [doesn’t that not even fit better than RBAC?]• Clark-Wilson (transaction based, objective: integrity)• Take-Grant (graph model for permission distribution)

Bell-LaPadula (No Read-Up/No Write-Down) vs. Biba (No Read-Down/No Write-Up)?• Bell-LaPadula has a focus on confidentiality (e. g. processing of patient data) within

information flows while Biba focuses on integrity (e. g. config of devices by admins and users).

from my point of view, MAC does not fit well for complex healthcare scenarios, even though it allows for good and easy solutions on rudimentary intra-enterprise AC

15

2.1.3 Policy Based Access Control

Policy: rules for controlling the behaviour of a system

PEP: interception and decision enforcement (missing: obligation activation)

PDP: policy decision, [policy retrieval, attribute retrieval (conceptual model)]

PIP: attribute value source• wording?• part of the diagram?

PAP: policy authority, policy activation• wording?• part of the diagram?

16

2.2 SOA Security Principles

Comment: Include a short description of SAML, XACML, WS Trust

Security Token, STS are used to denote concepts/patterns, not WS Trust components• change wording?

17

2.3 Access Control System

An Access Control System (ACS) is a (logical) capsule around all authorization subsystem components that are (logically) linked with a node.

ACS = Access Control System / Service / Subsystem?

18

2.3 Access Control System

A common ACS is able to integrate components for the• Management of policies and attributes• Policy decision and policy enforcement• Security token issuing and verification (for ACS federation)

Other functionalities that should be mentioned?

19

2.3.1 Access Control System: Building Blocks

20

2.3.1 Access Control System: Building Blocks

These building blocks – which will be discussed in depth throughout the rest of this white paper - are:

• policy authority services for the management, selection, and activation of policies.

• attribute services for managing attributes an subjects, resources, etc. which have to be considered for the evaluation of policy rules

• security token services for the establishment of trust relationships to remote ACS and for the secure (with respect to integrity and authenticity) exchange of attributes and policies across domains.

• Policy enforcement and decision points which apply policies on business service requests. It is assumed that (at least on a model level) each request is mediated through the PEPs of the communicating nodes.

21

2.3.2 Access Control System: Domains (Wording?)

22

2.3.3 Federated Healthcare Environments (Wording?)

Given a circle of trust, two major federation scenarios have to be considered:• federation of resource domains: A context domain is able to request

protected resources from multiple resource domains. Therefore the ACS at the context domain has to be able to share application semantics and policies with ACSs within multiple resource domains. This includes the ability of all attribute managing domains to provide attribute values in a way that can be understood by the domain that decides on the policy.

• federation of subject domains: A resource domain accepts requests from subjects that reside in different subject domains. By federating identities, subject domains are able to discover, exchange, and synchronize attributes that relate to the same subject.

Other scenarios?

semantic interoperability as an issue?

23

2.3.4 IHE Profiles

24

XUA, EUA, PWP

The Cross-Enterprise User Assertion (XUA) integration profile provides mechanisms to exchange authenticated subject information across domain boundaries. It is therefore well suited for connecting the subject domain to the circle of trust.

By combining XUA and Kerberos-based Enterprise User Authentication (EUA) an already IHE compliant enterprise can run its own identity provider using existing technology.

The Personnel White Pages (PWP) integration profile defines how organizations might maintain attributes describing their personnel based on common LDAP technology.

By either integrating this information into XUA or by providing it to external users through security tokens (e. g. using an STS-safeguarded policy information point) the subject domain’s required functionality can be provided by already existing IHE profiles.

25

BPPC, XDS

The Basic Patient Privacy Consent (BPPC) integration profile describes how XDS registries and repositories can be used for maintaining privacy policies.

This allows for setting up a policy authority within the resource domain. By encapsulating this functionality by a security token service, privacy policies can even be exchanged in a secure manner across domain boundaries.

XDS registries are designated for the management and provisioning of resource attributes and as such provide the functionality of an attribute service.

26

Conclusion

Using existing profiles for the management of policies and resource attributes at the resource domain and for the trusted exchange of subject attributes among domains, even rather complex access control scenarios can be implemented.

Grouping table, etc?

The major white spots not recently covered by IHE integration profiles are PEP/PDP and policy authorities which are decoupled from the resource managing systems. [Agreement? Other white spots?]

Possible strategies for evolving in this direction are discussed in section 4.x of this white paper. [Agreement?]

27

Chapter 3: Policies and Attributes (1/2)

Session Control vs. Resource Control • Granularities and flavours of protected resources • The role of the “Purpose”

Resource Security through Role Based Access Control • Needs-to-know principle• role engineering and access control matrices • Role activation

The Role of the Patient • Patient Privacy Policies (Consents) • Prefetching of patient data • patient-bound tokens (e. g. EHCs) as access control measures

28

Chapter 3: Policies and Attributes (2/2)

Instantiation of access rights for organizations (section title must be changed!!)• Integration of AC Paradigms • Policy conflicts• client-side vs. resource-side enforcement

Conclusion: Policies and Attributes Needed • patient privacy policy, application policy, resource (data

protection) policy • subject attributes, resource attributes, activity attributes,

context/purpose attributes, patient attributes • policy templates • Binding of policies and attributes (and attribute sources)

29

Applications as Legal Frameworks

XDS: Shared Medical Data

Privacy Policy

Security Policy

Purpose of Use

EHR, PHR, eCR, ...

App. Policy

activates

30

Needs-to-Know Principle (e. g. Treatment Contract)

Organizational Structure(Who? Why? What?)

Medical Treatm

ent

Data Processing

Acce

ss De

man

ds

(Autho

rization

)

Role

Context/Purpose

Permissions

The objective of access control is to provide all physicians the information theyneed to know in order to treat the patient the best way

- while respecting the patient’s right towards self-determination- while protecting the confidentiality and integrity of medical data

31

Resource Access Policy:Who is allowed to access my EHRfor the given purpose/context?

ResourceBehaviour Policy:

How may authorizedsubjects work with my

EHR?

EHR Definition

Privacy Consent National Law

Agr

eem

ent

Con

figur

atio

n

Authorization Scope, Procedure, ...

Regulations

Access Policies vs. Behaviour Policies (THIS ONE...)

32

Combination of DAC and RBAC [... OR THIS ONE?]

RBAC

clinic

RBAC

GP

DAC

sync

patient decides which organizations take part in a co-operative medical treatment for a certain disease. Only staff members of these organizations may access his shared data.

organization of labor at clinic and practice determines which roles may access which portions of the patient’s shared data

33policy

subject-ID

role-ID (adm)

policy activation

context-ID

purpose-ID

role-ID (func)

patient-ID

resource-ID

activity-ID

policy consumer

representspolicy-ID *

attribute value *

policy decision

resource provider

attribute value *

policy-ID *

evaluates

acceptor deny

...

res.type-ID

Attributes and Policies

34

Policy Template

CIS

Clinic B

CIS

Clinic A

Consent

exchange

I hereby authorise Clinic A to share all my diabetes-related medical data with diabetologists at Clinic B in case that I require a treatment while I am at Clinic B.

I hereby authorise [organizations] to share all my [kind-of] medical data with [roles] at [organizations] in case that I require a [purpose] while I am at [orgs].

instantiate

35

Using Policy Templates for Attribute Binding