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

2 Editing Team Authors:Raik Kuhlisch, Jörg Caumanns // Fraunhofer ISST Oliver Pfaff, Markus Franke // Siemens IT Solutions // and Services Christof Strack, Heiko Lemke// SUN Microsystems Supervisior:Rob Horn// Agfa Healthcare Editorial Team:John Moehrke// GE Healthcare Lynn 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 1finalized, minor open issues Chapter 2finalized, minor open issues Chapter 31st draft, open issues from last TCon Chapter 4Outline (this slides) Chapter 5Examples will be distributed/commented on by Chapter 6Outline 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-ID res.type-ID policy decision policy activation lab data physician treatment clinic A resource ID my data App-ID Historical 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-ID res.type-ID policy decision policy activation lab data physician treatment clinic A context attribute subject attribute context attribute subject attribute resource attribute resource ID my data resource attribute App-ID context 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 ACS STS Context Domain ACS STS Subject Domain ACS STS Patient Domain ACS STS 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 ACS STS Context Domain ACS STS Subject Domain ACS STS Patient Domain ACS STS 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 Application Domain ACS STS application attributes PEP / PDP app. security policy org. security policy

12 Use-Cases: Alignment to Domain Model ACS STS Context Domain ACS STS Subject Domain ACS STS Patient Domain ACS STS 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 involved in treatment role physician repres. of Clinic A lab data Patient Privacy Policy: org: Clinic A role: physician purpose: Treatment kind-of: lab data

13 Use-Case: Attributes Context Domain STS 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 ID app ID

14 Use-Case: Policy Context Domain STS 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 ID app ID

15 Core Methodology (Runtime) 1.Service Request 2.Authorization Request Generation Business Service Configuration Requestor 1 2 Access Control System

16 Use-Case: Initial Flow of Control Context Domain STS Subject Domain STS Patient Domain 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 ID app ID

17 Core Methodology (Runtime) 2. Authorization Request Processing (Policy Discovery and Evaluation) Application Resource PDP PEP Policy Finder Configuration Policy Policy Service Management ACS

18 Use-Case: Policy Retrieval Context Domain STS Subject Domain STS Patient Domain 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 ID app ID

19 Use-Case: Attribute Flow Context Domain STS Subject Domain STS Patient Domain 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 patient ID purpose ID patient ID subject ID org ID subject role org ID XUA app ID

20 Use-Case: Attribute Flow [Minimum Infrastructure Mode] Context Domain STS Subject Domain STS Patient Domain Resource Domain 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 XUA app ID

21 Use-Case: Single Sign-On Context Domain STS Subject Domain STS Patient Domain 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 patient ID purpose ID subject role patient ID org ID subject ID subject role org ID XUA app ID

22 Configuration Opportunities 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

24 Use-Case: Policy Push Context Domain STS Subject Domain STS Patient Domain Resource Domain 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 org ID 1 patient ID org ID subject roleXUA subject role org ID XUA app ID

25 Attribute Pull (PIP) vs. Attribute Push PDP Requestor Resource PEP PIP PDP Requestor Resource PEP PIP Service Request without Attributes (PULL) Service Request with Attributes (PUSH)

26 Use-Case: Attribute Pull, Policy Push Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PEP / PDP request initiator resource subject role patient ID org ID resource type patient ID purpose ID patient ID policy XUA subject ID app ID

27 Use-Case: Attribute Pull, Policy Pull Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PEP / PDP request initiator resource subject role patient ID resource type patient ID purpose ID patient ID org ID XUA subject ID app ID

28 Use-Case: Attribute Pull, Policy Cache Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PEP / PDP request initiator resource subject role patient ID resource type policy ID purpose ID patient ID org ID XUA subject ID patient ID policy ID 4 app ID

29 Use-Case: Split PEP/PDP Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PDP request initiator resource subject role patient ID resource type patient ID subject ID org ID PEP resource ID policy decision STS 3 app ID

30 Use-Case: Client-side PEP/PDP Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PEP / PDP request initiator resource subject role patient ID resource type patient ID subject ID org ID patient ID subject ID app ID

31 Use-Case: Client-side PEP/PDP with SSO STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PEP / PDP request initiator resource subject role resource type patient ID org ID patient ID subject ID patient ID org ID XUAsubject role Context Domain 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