1 IHE ITI White Paper on Access Control Outline of Chapter 4 Jörg Caumanns, Raik Kuhlisch, Olaf Rode TCon, 10.03.09

1

IHE ITI White Paper on Access Control

Outline of Chapter 4

Jörg Caumanns, Raik Kuhlisch, Olaf Rode

TCon, 10.03.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 // MIR

Manuel Metz // GIP-DMP

3

Revised Table of Contents

Chapter 1: Access Control Scenarios in Healthcare (Introduction)

Chapter 2: Fundamentals of Access Control

Chapter 3: Policies and Attributes

Chapter 4: Actors and Transactions

Chapter 5: Examples

Chapter 6: Deployment and Implementation

4

Status

Chapter 1 finalized, minor open issues

Chapter 2 finalized, minor open issues

Chapter 3 1st draft, open issues from last TCon

Chapter 4 Outline (this slides)

Chapter 5 Examples will be distributed/commented on by e-Mail

Chapter 6 Outline subject to TCon on March, 31

5

Extension to Chapter 3: Storyboard and Sample Scenario

Storyboard

In the Berlin area several hospitals set up a network for the exchange of medical patient data.

A dedicated application is designed on top of this network that enables physicians to easily access historical data that might be relevant for 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

6

Use-Cases: Exemplary Consent

I hereby authorise physicians at Clinic A to use the “Historical Database” Application in order to access all my lab data for the purpose of medical treatment.

I hereby authorise [roles] at [organizations] to use the “Historical Database” Application in order to access all [Patient] [kind-of-data] for the purpose of [purpose].

instantiate

7

Attribute Stub Definition (Example)

Patient Consent: I hereby authorise physicians at Clinic A to use the “Historical Database” Application in order to access all my lab data for the purpose of medical treatment.

policy instance

role-ID

org-ID

purpose-ID

patient-IDres.type-ID

policy decisionpolicy activation

lab data

physician

treatment

clinic A

resource ID my data

App-IDHistorical DB

8

Attribute Stub Definition (Example)

Patient Consent: I hereby authorise physicians at Clinic A to use the “Historical Database” Application in order to access all my lab data for the purpose of medical treatment.

policy instance

role-ID

org-ID

purpose-ID

patient-IDres.type-ID

policy decisionpolicy activation

lab data

physician

treatment

clinic A

context attribute

subject attribute

context attribute

subject attribute

resource attributeresource ID my data

resource attribute

App-IDcontext attr.

9

Chapter 4: Actors and Transactions

4.1 Domains and Actors

4.2 Generic Flow of Control

4.3 Configuration Options

4.4 Actor-Transaction Model

10

4-Domain Model

ACSSTS

Context Domain

ACSSTS

Subject Domain

ACSSTS

Patient Domain

ACSSTS

Resource Domain

patient privacy policy (consent)

context attributes subject attributes

resource attributes

role activation

consent activation

Identity Prv.

PEP / PDP org. security policy

request initiator

resource

Attribute Svc.PEP / PDP

org. security policy

11

5-Domain Model

ACSSTS

Context DomainACS

STS

Subject Domain

ACSSTS

Patient DomainACS

STS

Resource Domain


context attributes

subject attributes

resource attributes

role activation

consent activation

Identity Prv.


request initiator

resource

Attribute Svc.

PEP / PDP

Application Domain

ACSSTS

application attributes

PEP / PDP app. security policy

org. security policy

12

Use-Cases: Alignment to Domain Model

ACSSTS

Context DomainACS

STS

Subject Domain

ACSSTS

Patient Domain

ACSSTS

Resource Domain


context attributes

subject attributes

resource attributes

role activation

consent activation

Identity Prv.


request initiator

resource

Attribute Svc.

PEP / PDP

involved intreatment role physician

repres. of Clinic A

lab data

Patient Privacy Policy: org: Clinic A role: physicianpurpose: Treatment kind-of: lab data

13

Use-Case: Attributes

Context DomainSTS

Subject Domain

ACS

Resource Domain

purpose ID

resource ID

role activation Identity Prv.

PEP / PDP

request initiator

resource

subject role

patient ID

org ID

resource type

STS

subject ID

org IDapp ID

14

Use-Case: Policy

Context DomainSTS

Subject Domain

STS

Patient Domain

ACS

Resource Domain

patient privacy policy

purpose ID

resource ID

role activation

policy activation

Identity Prv.

PEP / PDP

request initiator

resource

subject role

patient ID

org ID

resource type

STS

subject ID

org IDapp ID

15

Core Methodology (Runtime)

1. Service Request

2. Authorization Request Generation

Business ServiceConfiguration

Requestor1

2

Access Control System

16

Use-Case: Initial Flow of Control

Context DomainSTS

Subject Domain

STS

Patient DomainResource Domain


purpose ID

resource ID

role activation

policy activation

Identity Prv.

PEP / PDP

request initiator

resource

subject role

patient ID

org ID

resource type

STS

subject ID

org IDapp ID

17

Core Methodology (Runtime)

2. Authorization Request Processing

(Policy Discovery and Evaluation)

Application

Resource

PDP PEPPolicy Finder

Configuration

Policy

Policy ServiceManagement

ACS

18

Use-Case: Policy Retrieval

Context DomainSTS

Subject Domain

STS



purpose ID

resource ID

role activation

policy activation

Identity Prv.

PEP / PDP

request initiator

resource

subject role

patient ID

org ID

resource type

STS

1

2

3

4

subject ID

org IDapp ID

19

Use-Case: Attribute Flow

Context DomainSTS

Subject Domain

STS



purpose ID

resource ID

role activation

policy activation

Identity Prv.

PEP / PDP

request initiator

resource

subject role

patient ID

org ID

resource type

STS

patient ID

purpose ID

patient ID

subject ID

subject IDorg ID

subject roleorg ID

XUA

XUA

app ID

app ID

app ID

20

Use-Case: Attribute Flow [Minimum Infrastructure Mode]

Context DomainSTS

Subject Domain

STS


default policy

purpose ID

resource ID

role activation

policy activation

Identity Prv.

PEP / PDP

request initiator

resource

subject role

patient ID

org ID

resource type

STS

purpose ID

patient ID

subject ID

org ID

org IDXUA

app ID

21

Use-Case: Single Sign-On

Context DomainSTS

Subject Domain

STS



purpose ID

resource ID

role activation

policy activation

Identity Prv.

PEP / PDP

request initiator

resource

subject role

patient IDorg ID

resource type

STS

patient ID

purpose ID

subject role

patient ID

org ID

subject ID

subject role

org ID

XUA

XUA

app ID

app ID

app ID

22

Configuration Opportunities

may as well be pushed with request

may as well be pushed with request

may be pushed with request as security token

caller-side vs. resource-side enforcement

23

Policy Pull vs. Policy Push

Business Service

PEP PDP PAP

AuthorisationDecision Req.

AuthorisationDecision Resp.

AuthorisationPolicy Req.

AuthorisationPolicy Resp.

Business Srv.

PAP PEP PDP

AuthorisationDecision Req.

AuthorisationDecision Resp.

Authorisation Policy (piggybacked with request)

Authorisation Policy Pull

Authorisation Policy Push

24

Use-Case: Policy Push

Context DomainSTS

Subject Domain

STS


policy

purpose ID

resource ID

role activation

policy activation

Identity Prv.

PEP / PDP

request initiator

resource

subject role

resource type

STS

patient ID

purpose ID

patient ID

subject ID

policy

23

4

org ID

1

patient IDorg IDsubject role XUA

subject roleorg IDXUA

app ID

app ID

25

Attribute Pull (PIP) vs. Attribute Push

PDP

Requestor ResourcePEP

PIP PDP

Requestor ResourcePEPPIP

Service Request without Attributes

(PULL)

Service Request with Attributes

(PUSH)

26

Use-Case: Attribute Pull, Policy Push

Context DomainSTS

Subject Domain

STS


policy

purpose ID

resource IDpolicy activation

Attribute Svc

PEP / PDP

request initiator

resource

subject rolepatient ID

org ID

resource type

patient IDpurpose ID

patient ID

policy1

23

4

XUA

XUA subject ID

subject ID subject ID

app ID

app ID

27

Use-Case: Attribute Pull, Policy Pull

Context DomainSTS

Subject Domain

STS


policy

purpose ID


Attribute Svc

PEP / PDP

request initiator

resource


resource type

patient ID

purpose IDpatient ID

1

2

3

4

org ID

XUA

XUA subject ID

subject ID subject ID

app ID

app ID

app ID

28

Use-Case: Attribute Pull, Policy Cache

Context DomainSTS

Subject Domain

STS


policy

purpose ID


Attribute Svc

PEP / PDP

request initiator

resource


resource type

policy ID

purpose ID

patient ID

1

2

3

5

org ID

XUA

XUA subject ID

subject ID subject IDpatient ID

policy ID

4app ID

app ID

29

Use-Case: Split PEP/PDP

Context DomainSTS

Subject Domain

STS


policy

purpose ID


Attribute Svc

PDP

request initiator

resource


resource type

patient ID

subject ID

1

2

4

5

org ID

PEP

resource IDpolicy decision

STS

3

app ID

app ID

30

Use-Case: Client-side PEP/PDP

Context DomainSTS

Subject Domain

STS


policy

purpose ID

resource ID

policy activation

Attribute Svc

PEP / PDP

request initiator

resource


resource type

patient ID

subject ID

2

1

3

org ID

patient ID

subject ID

app ID

app ID

31

Use-Case: Client-side PEP/PDP with SSO

STS

Subject Domain

STS


policy

purpose ID

resource ID

policy activation

Attribute Svc

PEP / PDP

request initiator

resource

subject role

resource type

patient ID

1

23

org ID

patient ID

subject IDpatient IDorg IDXUAsubject role

Context Domainapp ID

app ID

32

Deployment and Evaluation

Deployment of the single domains (and their respective building block) onto nodes• subject domain in usually closely related to the context domain. But:

providing it close to the resource makes attribute pull easier• deployment of the patient domain depends on the use of pull/push and on

implementation issues (e. g. if XDS is used for policy management)

Evaluation of the various deployment opportunities with respect to• principles of secure design• management authorities and policies• security consideration (what assumptions can be made about the nodes’

security contexts)• ...

33

Conclusion

• Using the same set of building blocks (actors) and messages (transactions) very different flows of control can be realized in order to match the non-functional requirements of the application scenario.

• Different domains use building blocks with identical functionality and semantics. Therefore these blocks are generic in away that they are independent from their environment.

• There are different opportunities to implement the actors and transactions that make up the common building blocks. But: To allow for a multi-vendor strategy and for cross-enterprise communication these implementations must be interoperable.

• There is a need for interoperability profiles (comparable to XUA) for policy activation, attribute retrieval, and attribute/policy integration into transactions.

34

To be done: Definition of re-usable building blocks

Identity Provider Actor: XUA + Attributes (extension to XUA?)

Attribute Service Actor: encapsulates LDAP services; provides attribute values(if bound to requestor domain, PWP will do for now)

Role Activation Actor: receives XUA+ and provides functional role (no interop problem except agreement on codes; not conceptually mature)

Policy Activation Actor: 1. receives XUA+, attributes and provides policy or policy ID 2. receives policy-ID and provides policy -> BPPC-use of XDS?

PEP/PDP Actor: receives XUA+, attributes and (opt.) policy; consumes policy (opt); consumes attributes (opt.), provides policy decision, consumes audit trail

Documents

1 IHE ITI White Paper on Access Control Outline of Chapter 4 Jörg Caumanns, Raik Kuhlisch, Olaf Rode TCon, 10.03.09