Ihe iti white paper on authorization
This presentation is the property of its rightful owner.
Sponsored Links
1 / 26

IHE ITI White Paper on Authorization PowerPoint PPT Presentation


  • 58 Views
  • Uploaded on
  • Presentation posted in: General

IHE ITI White Paper on Authorization. Volume 1 Rough Cut Outline Jörg Caumanns, Raik Kuhlisch, Oliver Pfaff, Olaf Rode, Christof Strack, Heiko Lemke Berlin, 22.12.08. Editing Team.

Download Presentation

IHE ITI White Paper on Authorization

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Ihe iti white paper on authorization

IHE ITI White Paper on Authorization

Volume 1 Rough Cut

Outline

Jörg Caumanns, Raik Kuhlisch, Oliver Pfaff, Olaf Rode, Christof Strack, Heiko Lemke

Berlin, 22.12.08


Editing team

Editing Team

  • Authors:Raik Kuhlisch, Jörg Caumanns // Fraunhofer ISSTOliver Pfaff, Markus Franke // Siemens IT Solutions// and ServicesChristof Strack, Heiko Lemke// SUN Microsystems

  • Supervisior:Rob Horn// Agfa Healthcare

  • Editorial Team:John Moehrke// GE HealthcareLynn FelhoferManuel Metz// GIP-DMP


Schedule

Schedule

  • 06. JanInternal Face-to-Face Meeting (ISST, Siemens)

  • 07. JanInternal Online Meeting (ISST, Siemens, SUN)

  • 08. JanPreparation of Slides/Paper for the Editorial Team

  • 09. JanOnline Meeting with Editorial Team (19.00 MEZ)

  • 14. JanUpdate of Initial Paper for Internal Discussion

  • 16. JanInternal Online Meeting (ISST, Siemens, SUN, ELGA)

  • 19. JanDeadline for Internal Comments

  • 20. JanPreparation of the Initial Paper for the Editorial Team

  • 21. JanOnline Meeting with Editorial Team (16.00 MEZ)

  • 24. JanUpdate of Initial Paper and Preparation of ITI Technical Committee

  • 26.-29. JanFace-to-Face Meeting with ITI Technical Committee


Storyline of the white paper

Storyline of the White Paper

  • There is no “one-fits-all” solution for authorization

    • policies, verifiable attributes, and attribute sources vary

    • granularity of protected items varies

    • deployment varies

  • Therefore the WP provides a generic toolkit of deployable actors and a methodology to tailor this toolkit to a specific healthcare network’s needs and to identify the required transactions.

  • The toolkits reflects the maximal set of attributes and policy sources in a maximally distributed scenario. The methodology helps system architects in selecting the required components and in designing the optimized flow of control.

  • For each component and transaction appropriate standards are named. If possible they are mapped onto existing IHE ITI actors and transactions.


Outline

Outline

  • Access Control: Motivation and State-of-the-Art

  • Specific Requirements of Federated Healthcare Networks

  • Generic Access Control Model for Federated Healthcare Networks

  • Methodology for Tailoring the Generic Model

  • Sample Adaptations of the Generic Model

  • Standards for Implementing the Actors and Transactions of the Generic Model

  • Appendix: Glossary of Terms

  • Appendix: Standards and Vocabularies for Attribute Names and Values


Chapter 1 access control motivation and state of the art

Chapter 1: Access Control – Motivation and State of the Art

  • Motivation

    • Privacy and Data Security

    • Needs-to-Know Principle

  • State of the Art

    • Paradigms: DAC, MAC, RBAC, ...

    • Policy Based Access Control (PEP, PDP, ...)

    • Standards (SAML, WS*, XACML, XSPA, ...)

  • Challenge

    • Solution is driven by the characteristics of the policies: Which information is needed for policy selection/evaluation and how can this information be obtained in an efficient manner?

    • Multiple policy sources and specific workflow aspects add another layer of complexity

    • But: Things must be kept simple to be safe and efficient


Chapter 1 access control motivation and state of the art1

Chapter 1: Access Control – Motivation and State of the Art

  • Generic Model for Access Control (based on XSPA)

    • Access Control System within each domain

    • Attribute Management (Directories and Services)

  • Domain 1: Context Domains

    • Issuer of a request affecting a protected resource

    • Management of context attributes

    • control of the assertion/message flow

  • Domain 2: Subject Domain (in XSPA part of the issuing domain)

    • Subject authentication

    • Management of subject attributes

  • Domain 3: Resource Domain

    • management of protected resources (e. g. data base)

    • management of resource attributes

    • management of resource security policies

    • policy enforcement and policy decision


Generic model distributed xspa

Generic Model (distributed XSPA)

Subject Domain

Context Domain

ACS

ACS

subject attributes

context attributes

STS

STS

Attribute Svc.

role activation

PEP / PDP

Identity Prv.

request initiator

ACS

resource attributes

STS

org. security policy

PEP / PDP

resource

Resource Domain


Chapter 2 specific requirements of federated healthcare networks

Chapter 2: Specific Requirements of (Federated) Healthcare Networks

  • Federated Healthcare Environments

    • Trust Brokerage and Security Token

    • Federation of the Resource Domain (XCA)

    • Federated Identities within the Subject Domain (XUA)

    • Distributed Patient Attributes (XCPI)

  • Session Control vs. Resource Control

    • Granularities and flavours of protected resources

    • The role of the “Purpose”

    • Instantiation of access rights for organizations

  • Resource Security through Role Based Access Control

    • HL7 role engineering

    • Role activation

    • HL7/VA access control matrices


Chapter 2 specific requirements of federated healthcare networks1

Chapter 2: Specific Requirements of (Federated) Healthcare Networks

  • The Role of the Patient

    • Patient Privacy Policies (Consents)

    • DAC-style vs. RBAC-style PPPs

    • client-side vs. resource-side enforcement

    • patient-bound tokens (e. g. EHCs) as access control measures

  • 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

    • Binding of policies and attributes (and attribute sources)


Access control layering in healthcare

Access Control Layering in Healthcare

application contexts(purpose-driven)

medicationrecord

acute carerecord

electronic health record

e-prescriptionmanagement

session control(DAC-style)

federatedhealthcare infrastructure

resource control(RBAC-style)

medical resources(data-centric)


Session control

Session Control

  • In (distributed) medical treatment scenarios, access to medical data is legitimated by a purpose which is implemented by a medical application

  • It is the patient’s right to decide who may act on his data for which purpose. This is reflected by patient-granted admission rights for the corresponding medical services.

  • Examples for admission rights:

    • Person A and Organization B may access my EHR

    • Any physician to whom I handle over my EHC may access my medication record

  • Admission control is often implemented in a service-specific way; e.g.:

    • EHC tickets to access a patient’s e-prescriptions

    • eCR admission codes to access a patient’s case record


Resource control

Resource Control

  • The objective of resource control is to grant permissions (for operations on object types) to only the persons who need these permissions in order to perform their dedicated functional roles within a medical workflow

  • Resource control rights reflect the separation of concerns within an organization and are a measure of data security

  • Example for a resource control access right system:

    • HL7 healthcare scenario roadmap

  • Resource access rights can best be expressed using role-based policies. Nevertheless most existing hospital information systems use hard-coded access rules and proprietary permission hierarchies...


Chapter 3 generic acs model for federated healthcare networks

Chapter 3: Generic ACS Model for Federated Healthcare Networks

  • Extension and Refinement of the Generic Model (Chapter 1)

    • additional Patient Domain

    • 2 flavours of the resource domain:

      • resource domain

      • application domain

    • each domain controls attributes and policies

    • each domain may exist with none, one, or multiple instances


4 domain model distributed xspa

4-Domain Model (distributed XSPA)

Subject Domain

Context Domain

ACS

ACS

subject attributes

context attributes

STS

STS

Attribute Svc.

role activation

PEP / PDP

Identity Prv.

request initiator

ACS

ACS

resource attributes

consent activation

STS

STS

org. security policy

patient privacy policy (consent)

PEP / PDP

resource

Resource Domain

Patient Domain


5 domain model distributed xspa

5-Domain Model (distributed XSPA)

Subject Domain

Context Domain

ACS

subject attributes

STS

ACS

Attribute Svc.

context attributes

Identity Prv.

STS

role activation

PEP / PDP

request initiator

ACS

application attributes

STS

app. security policy

PEP / PDP

ACS

consent activation

STS

Application Domain

patient privacy policy (consent)

Patient Domain

ACS

resource attributes

STS

org. security policy

PEP / PDP

resource

Resource Domain


Chapter 3 generic acs model for federated healthcare networks1

Chapter 3: Generic ACS Model for Federated Healthcare Networks

  • Identification and Authentication

    • Subject Authentication (XUA)

    • Role Attributes and Role Activation

    • Patient Identification

  • Privacy Policy Activation and Session Control

    • Context Activation

    • Application Policy Selection

    • Privacy Policy Selection

    • Separation of DAC- and RBAC-style rules

    • Policy Decision and Enforcement (Context Domain)

    • Policy Decision and Enforcement (App Domain)


Chapter 3 generic acs model for federated healthcare networks2

Chapter 3: Generic ACS Model for Federated Healthcare Networks

  • Resource Control

    • Resource Policy Selection

    • Patient Privacy Policy Push vs. Pull

    • Resource Attribute Retrieval

    • Policy Decision and Enforcement

  • Actors and Transactions

    • Security Token Services, Policy Registries and Policy Repositories, Attribute Services (Directories), PEP and PDP

    • Security Token Retrieval, Policy Retrieval, Attribute Retrieval, Role Activation, Policy Decision and Enforcement

    • Management Interfaces


Chapter 4 methodology

Chapter 4: Methodology

  • Policy Determination

    • Session Control vs. Resource Control

    • Policy Authorities

    • Paradigms for Patient Privacy Policy, App Policy, Resource Policy

    • Policy Assignment (Indexing for Retrieval)

  • Attribute Identification

    • Identification of Attribute Stubs

    • Domain Assignment

    • Policy Assignment

    • Specification of Attribute Value Sources

  • Policy Management

    • Policy Encoding

    • Policy Deployment


Chapter 4 methodology1

Chapter 4: Methodology

  • Access Control Systems within the Domains

    • PEP/PDP Placement

    • Policy Retrieval (Pull/Push)

    • Attribute Retrieval (Pull/Push)

    • Authorization Request Interface

  • Integration of the ACSs into the Application Control Flow

    • Session Management (if required)

    • Mapping of Resource Requests onto Authorization Requests

    • Security Token Control Flow

  • Policy Lifecycle Management


Core methodology

Core Methodology

No Defaults:

AuthZ Model (DAC, MAC, RBAC, ...),

Attr. Types/Sources

Defaults:

Syntax of policies

App Request

App

Config

AuthZ Request

e. g. XACML

PDP

ACS

Policy Evaluation

Runtime

PolicyFinder

Query (XACML Policy (Set)ID, Target, ...)

Tooltime

Policy Svc

3. Policy Deployment

Management

2. Policy building by given syntax 

Policy

1. Define Attributes (Desired Values)

Configuration

Attribute Value Source

Subject

Attribute Stubs

¬ Subject

(Resource,App)

e .g. Org. Type

Internal

(Aut/SSO)

External

(Classes)

Datatype

ID


Chapter 5 sample adaptations of the generic model

Chapter 5: Sample Adaptations of the Generic Model

  • XSPA Actor Deployment and Flow of Control

  • Regional Healthcare Network Based on IHE XDS/XUA

  • Distributed EHR Based on IHE XDS/XCA/XUA

  • eCR Security Architecture

  • BPPC (Context Domain Enforcement vs. Resource Domain Enforcement)


4 domain model xspa control flow

11

10

2

1

4

5

3

7

8

9

6

4-Domain Model (XSPA control flow)

Subject Domain

Context Domain

ACS

ACS

subject attributes

context attributes

STS

STS

Attribute Svc.

role activation

PEP / PDP

Identity Prv.

request initiator

ACS

ACS

resource attributes

consent activation

STS

STS

org. security policy

patient privacy policy (consent)

PEP / PDP

resource

Resource Domain

Patient Domain


Chapter 6 standards

Chapter 6: Standards

  • Layering Opportunities (Message Header, SOAP Header, SOAP Body)

  • Security Token Encoding and Exchange

    • SAML and WS Trust

    • Subject authentication and subject attribute exchange based on XUA (Protection Token)

    • Encoding and exchange of policy references and policies as security tokens (Supporting Token)

  • Policy Encoding

    • XACML

  • Attribute Management and Attribute Retrieval

    • PWP, PDQ, ...


Appendix a glossary of terms

Appendix A: Glossary of Terms

  • ResourceSomething of value in a network infrastructure to whichrules or policy criteria are first applied before access is granted [RFC 2753]

  • SubjectIdentified and authenticated entity (e. g. a human actor)who wants to access a resource

  • PolicySet of rules to administer, manage, and control accessto [network] resources [RFC 3060]

  • ConditionRepresentation of the necessary state and/or prerequi-sites that define whether a policy rule’s actions shouldbe performed [RFC 3198]


Appendix b standards and vocabularies for attribute names and values

Appendix B: Standards and Vocabularies for Attribute Names and Values

  • Subject Attributes

    • Administrative Roles

    • Functional Roles

    • Organizational Memberships

    • Organization Types

  • Patient Attributes (if anything but the ID is needed at all)

  • Context Attributes

    • Purpose

    • Date and Time

  • Application Attributes (if anything but the ID is needed at all)

  • Resource Attributes

    • Resource Type


  • Login