ITI Access Control White Paper: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
JohnMoehrke (talk | contribs)
No edit summary
 
(61 intermediate revisions by 4 users not shown)
Line 1: Line 1:
[http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_AccessControl_2009-09-28.pdf Access Control White Paper] Final Text - 2009-09-28


= Editorial Team =
= Editorial Team =
'''Authors'''
'''Authors'''
* Raik Kuhlisch (Fraunhofer ISST)
* Raik Kuhlisch (Fraunhofer ISST)
* Jörg Caumanns (Fraunhofer ISST)
* [[User:Joerg.caumanns| Jörg Caumanns]] (Fraunhofer ISST)
* Oliver Pfaff (Siemens IT Solutions and Services)
* Oliver Pfaff (Siemens IT Solutions and Services)
* Markus Franke (Siemens IT Solutions and Services)
* Markus Franke (Siemens IT Solutions and Services)
Line 14: Line 15:
* Lynn Felhofer (Mallinckrodt Institute of Radiology)
* Lynn Felhofer (Mallinckrodt Institute of Radiology)
* Manuel Metz (GIP-DMP)
* Manuel Metz (GIP-DMP)


= Schedule =
= Schedule =
Line 35: Line 33:
| Discussion
| Discussion
| Access Control White Paper
| Access Control White Paper
| [ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr7-2009-2010/Technical_Cmte/Whitepaper_Work/Access_Control_White_Paper/081219%20rough%20cut%20v02.ppt Rough Cut]
| [ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr7-2009-2010/Technical_Cmte/Whitepaper_Work/Access_Control_White_Paper/04_Workshops/090109_rough_cut_v02.ppt Slides]
| [[Minutes_Nov_2008_-_Sep_2009#Agenda Jan 9 12:00-14:00 | Agenda ]]
| [[Minutes_Nov_2008_-_Sep_2009#Agenda Jan 9 12:00-14:00 | Agenda ]]
| [[Minutes_Nov_2008_-_Sep_2009#Minutes Jan 9 12:00-14:00 | Minutes ]]
| [[Minutes_Nov_2008_-_Sep_2009#Minutes Jan 9 12:00-14:00 | Minutes ]]
Line 44: Line 42:
| Discussion
| Discussion
| Access Control White Paper
| Access Control White Paper
| -
| [ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr7-2009-2010/Technical_Cmte/Whitepaper_Work/Access_Control_White_Paper/04_Workshops/090113_BPPC_Opportunities_v01.ppt Slides]
| [[Minutes_Nov_2008_-_Sep_2009#Agenda Jan 21 9:00-10:00 | Agenda ]]
| [[Minutes_Nov_2008_-_Sep_2009#Agenda Jan 21 9:00-10:00 | Agenda ]]
| [[Minutes_Nov_2008_-_Sep_2009#Minutes Jan 21 9:00-10:00 | Minutes ]]
| [[Minutes_Nov_2008_-_Sep_2009#Minutes Jan 21 9:00-10:00 | Minutes ]]
|-
|-
| 2009.01.26-29
| 2009.01.26
| All day ''(b)''
| 1730-1900
| Chicago ([[Minutes_Nov_2008_-_Sep_2009#Logistics Jan 26-29 | Logistics ]])
| '''Decision'''
| Decide technical direction of profiles
| -
| TBD <!--[[Minutes_Nov_2008_-_Sep_2009#Agenda Jan 26-29 | Agenda ]]-->
| TBD <!--[[Minutes_Nov_2008_-_Sep_2009#Minutes Jan 26-29 | Minutes ]]-->
|-
| 2009.01.28
| 1700-1900
| Chicago ([[Minutes_Nov_2008_-_Sep_2009#Logistics Jan 26-29 | Logistics ]])
| Chicago ([[Minutes_Nov_2008_-_Sep_2009#Logistics Jan 26-29 | Logistics ]])
| '''Decision'''
| '''Decision'''
Line 92: Line 99:
= Outline =
= Outline =


#Access Control: Motivation and State-of-the-Art
'''Note:''' Some of the level-2-headings provide links to text blocks and figures on the respective topic
##Motivation
<p>
###Privacy and Data Security
== Access Control in Healthcare ==
###Needs-to-Know Principle
#[[ACWP_Motivation|Motivation]] <font color=red>[2nd draft, open issues pending]</font>
##State of the Art
#[[ACWP_Typical_AC_Scenarios_in_Healthcare|Access Control Scenarios in Healthcare]] <font color=red>[2nd draft, open issues pending]</font>
###Paradigms: DAC, MAC, RBAC, ...
#[[ACWP_Objective_and_Outline|Objective and Outline of the White Paper]] <font color=red>[2nd draft, ToC missing]</font>
###Policy Based Access Control (PEP, PDP, ...)
 
###Standards (SAML, WS*, XACML, XSPA, ...)
== Fundamentals of Access Control ==
##Challenge
#[[ACWP_Chapter2_Intro|Chapter Intro]] <font color=red>[1st draft, ready for review]</font>
###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?
#[[ACWP_State_of_the_Art|State of the Art]] <font color=red>[2nd draft, open issues pending]</font>
###Multiple policy sources and specific workflow aspects add another layer of complexity
##Principles of Secure Design
###But: Things must be kept simple to be safe and efficient
##Common Access Control Models
##Generic Model for Access Control (based on XSPA)
##Policy Based Access Control
###Access Control System within each domain
#[[ACWO_SOA_Security|SOA Security Principles]] <font color=red>[2nd draft]</font>
###Attribute Management (Directories and Services)
#[[ACWP_Generic_Model_for_AC|Access Control System]] <font color=red>[2nd draft]</font>
###Context Domain
##Building blocks
####Issuer of a request affecting a protected resource
##Access Control Domains
####Management of context attributes
####control of the assertion/message flow
###Subject Domain (in XSPA part of the issuing domain)
####Subject authentication
####Management of subject attributes
###Resource Domain
####management of protected resources (e. g. data base)
####management of resource attributes
####management of resource security policies
####policy enforcement and policy decision
#Specific Requirements of Federated Healthcare Networks
##Federated Healthcare Environments
##Federated Healthcare Environments
###Trust Brokerage and Security Token
##IHE Profiles
###Federation of the Resource Domain (XCA)
 
###Federated Identities within the Subject Domain (XUA)
== Policies and Attributes ==
###Distributed Patient Attributes (XCPI)
#Session Control vs. Resource Control
##Session Control vs. Resource Control
##Granularities and flavours of protected resources
###Granularities and flavours of protected resources
##Automatted workflows
###The role of the “Purpose”  
##The role of the “Purpose”  
###Instantiation of access rights for organizations
##Instantiation of access rights for organizations
##Resource Security through Role Based Access Control
#[[WPAC_Resource_Security_RBAC|Resource Security through Role Based Access Control]]
###HL7 role engineering
##Needs-to-Know Principle
###Role activation
##HL7 role engineering
###HL7/VA access control matrices
##Role activation
##The Role of the Patient
##HL7/VA access control matrices
###Patient Privacy Policies (Consents)
#[[WPAC_The Role of the Patient|The Role of the Patient]]
###DAC-style vs. RBAC-style PPPs
##Patient Privacy Policies (Consents)
###client-side vs. resource-side enforcement
##DAC-style vs. RBAC-style PPPs
###patient-bound tokens (e. g. EHCs) as access control measures
##Opt-Out considered harmful
##Conclusion: Policies and Attributes Needed
##client-side vs. resource-side enforcement
###patient privacy policy, application policy, resource (data protection) policy
##patient-bound tokens (e. g. EHCs) as access control measures
###subject attributes, resource attributes, activity attributes, context/purpose attributes, patient attributes
#[[WPAC_Conclusion_Policies_and_Attributes|Conclusion: Policies and Attributes Needed]]
###Binding of policies and attributes (and attribute sources)
##patient privacy policy, application policy, resource (data protection) policy
#Generic Access Control Model for Federated Healthcare Networks
##subject attributes, resource attributes, activity attributes, context/purpose attributes, patient attributes
##Extension and Refinement of the Generic Model (Chapter 1)
##Binding of policies and attributes (and attribute sources)
###additional Patient Domain
 
###2 flavours of the resource domain:
== Generic Access Control Model for Federated Healthcare Networks ==
####resource domain
#Extension and Refinement of the Generic Model (Chapter 1)
####application domain
##additional Patient Domain
###each domain controls attributes and policies
##2 flavours of the resource domain:
###each domain may exist with none, one, or multiple instances
###resource domain
##Identification and Authentication
###application domain
###Subject Authentication (XUA)
##each domain controls attributes and policies
###Role Attributes and Role Activation
##each domain may exist with none, one, or multiple instances
###Patient Identification
#Identification and Authentication
##Privacy Policy Activation and Session Control  
##Subject Authentication (XUA)
###Context Activation
##Role Attributes and Role Activation
###Application Policy Selection
##Patient Identification
###Privacy Policy Selection
#Privacy Policy Activation and Session Control  
###Separation of DAC- and RBAC-style rules
##Context Activation
###Policy Decision and Enforcement (Context Domain)
##Application Policy Selection
###Policy Decision and Enforcement (App Domain)
##Privacy Policy Selection
##Resource Control
##Separation of DAC- and RBAC-style rules
###Resource Policy Selection
##Policy Decision and Enforcement (Context Domain)
###Patient Privacy Policy Push vs. Pull
##Policy Decision and Enforcement (App Domain)
###Resource Attribute Retrieval
#Resource Control
###Policy Decision and Enforcement
##Resource Policy Selection
##Actors and Transactions
##Patient Privacy Policy Push vs. Pull
###Security Token Services, Policy Registries and Policy Repositories, Attribute Services (Directories), PEP and PDP
##Resource Attribute Retrieval
###Security Token Retrieval, Policy Retrieval, Attribute Retrieval, Role Activation, Policy Decision and Enforcement
##Policy Decision and Enforcement
###Management Interfaces
#Actors and Transactions
#Methodology for Tailoring the Generic Model
##Security Token Services, Policy Registries and Policy Repositories, Attribute Services (Directories), PEP and PDP
##Policy Determination
##Security Token Retrieval, Policy Retrieval, Attribute Retrieval, Role Activation, Policy Decision and Enforcement
###Session Control vs. Resource Control
##Management Interfaces
###Policy Authorities
 
###Paradigms for Patient Privacy Policy, App Policy, Resource Policy
== Sample Adaptations of the Generic Model ==
###Policy Assignment (Indexing for Retrieval)
#XSPA Actor Deployment and Flow of Control
##Attribute Identification
#Regional Healthcare Network Based on IHE XDS/XUA
###Identification of Attribute Stubs
#Distributed EHR Based on IHE XDS/XCA/XUA
###Domain Assignment
#[[eCR Security Architecture]] <font color=red>[under construction]</font>
###Policy Assignment
#[[BPPC with context-side/resource-side PEP]] <font color=red>[under construction]</font>
###Specification of Attribute Value Sources
 
##Policy Management
== Methodology for Tailoring the Generic Model ==
###Policy Encoding
#[[ACWP_Methodology_Introduction|Introduction]]
###Policy Deployment
#Policy Determination and Permission Catalogue
##Access Control Systems within the Domains
##Protection Demands (Session Control vs. Resource Control)
###PEP/PDP Placement
##Policy Authorities
###Policy Retrieval (Pull/Push)
##Policy Paradigms
###Attribute Retrieval (Pull/Push)
##Identification of Attribute Stubs
###Authorization Request Interface
##Policy Assignment (Indexing for Retrieval)
##Integration of the ACSs into the Application Control Flow
#[[ACWP_Methodology_Attribute_Management|Attribute Management]]
###Session Management (if required)
##Classification of Attribute Stubs
###Mapping of Resource Requests onto Authorization Requests
##Domain Assignment
###Security Token Control Flow
##Policy Assignment
##Policy Lifecycle Management
##Specification of Attribute Value Sources
#Sample Adaptations of the Generic Model
#Policy Management
##XSPA Actor Deployment and Flow of Control
##Protection Granularity (Permissions)
##Regional Healthcare Network Based on IHE XDS/XUA
##Distributed EHR Based on IHE XDS/XCA/XUA
##eCR Security Architecture
##BPPC with context-side/resource-side PEP
#Standards for Implementing the Actors and Transactions of the Generic Model
##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
##Policy Encoding
###XACML
##Policy Deployment
##Attribute Management and Attribute Retrieval
#[[ACWP_Methodology_ACS_Domains|Access Control Systems within the Domains]]
###PWP, PDQ, ...
##PEP/PDP Placement
#Appendix: Glossary of Terms
##Authorization Request Interface
#Appendix: Standards and Vocabularies for Attribute Names and Values
##Policy Retrieval (Pull/Push)
##Attribute Retrieval (Pull/Push)
#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
 
== Standards for Implementing the Actors and Transactions of the Generic Model ==
#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 B: Standards and Vocabularies for Attribute Names and Values ==




Line 233: Line 240:




= References =
IHE IT Infrastructure White Paper: ''HIE Security and Privacy through IHE Profiles''.
Version 2.0, August 22, 2008.
([http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Whitepaper_Security_and_Privacy_of_HIE_2008-08-22-2.pdf PDF])
<br>
<br>


= Detailed proposal =
= Detailed proposal =
[ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr7-2009-2010/Technical_Cmte/Meetings/2008_Nov_f2f/Detailed_Proposals/XPP-Presentation_revised.ppt Access control white paper detailed proposal]
[ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr7-2009-2010/Technical_Cmte/Meetings/2008_Nov_f2f/Detailed_Proposals/XPP-Presentation_revised.ppt Access control white paper detailed proposal]

Latest revision as of 08:04, 2 April 2010

Access Control White Paper Final Text - 2009-09-28

Editorial Team

Authors

  • Raik Kuhlisch (Fraunhofer ISST)
  • Jörg Caumanns (Fraunhofer ISST)
  • Oliver Pfaff (Siemens IT Solutions and Services)
  • Markus Franke (Siemens IT Solutions and Services)
  • Christof Strack (SUN Microsystems)
  • Heiko Lemke (SUN Microsystems)

Supervisor

  • Rob Horn (Agfa Healthcare)

IHE ITI Editorial Team

  • John Moehrke (GE Healthcare)
  • Lynn Felhofer (Mallinckrodt Institute of Radiology)
  • Manuel Metz (GIP-DMP)

Schedule

Date Time (MEZ) Location Type (a) Topic Slides Agenda Minutes
2009.01.09 1900-2100 T-con ( Logistics ) Discussion Access Control White Paper Slides Agenda Minutes
2009.01.21 1600-1800 T-con ( Logistics ) Discussion Access Control White Paper Slides Agenda Minutes
2009.01.26 1730-1900 Chicago ( Logistics ) Decision Decide technical direction of profiles - TBD TBD
2009.01.28 1700-1900 Chicago ( Logistics ) Decision Decide technical direction of profiles - TBD TBD
2009.05.04-08 All day (b) Chicago ( Logistics ) Decision Prepare profiles for public comments - TBD TBD
2009.07.13-17 All day (b) Chicago ( Logistics ) Decision Prepare profiles for trial implementation - TBD TBD

Storyline

  • 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

Note: Some of the level-2-headings provide links to text blocks and figures on the respective topic

Access Control in Healthcare

  1. Motivation [2nd draft, open issues pending]
  2. Access Control Scenarios in Healthcare [2nd draft, open issues pending]
  3. Objective and Outline of the White Paper [2nd draft, ToC missing]

Fundamentals of Access Control

  1. Chapter Intro [1st draft, ready for review]
  2. State of the Art [2nd draft, open issues pending]
    1. Principles of Secure Design
    2. Common Access Control Models
    3. Policy Based Access Control
  3. SOA Security Principles [2nd draft]
  4. Access Control System [2nd draft]
    1. Building blocks
    2. Access Control Domains
    3. Federated Healthcare Environments
    4. IHE Profiles

Policies and Attributes

  1. Session Control vs. Resource Control
    1. Granularities and flavours of protected resources
    2. Automatted workflows
    3. The role of the “Purpose”
    4. Instantiation of access rights for organizations
  2. Resource Security through Role Based Access Control
    1. Needs-to-Know Principle
    2. HL7 role engineering
    3. Role activation
    4. HL7/VA access control matrices
  3. The Role of the Patient
    1. Patient Privacy Policies (Consents)
    2. DAC-style vs. RBAC-style PPPs
    3. Opt-Out considered harmful
    4. client-side vs. resource-side enforcement
    5. patient-bound tokens (e. g. EHCs) as access control measures
  4. Conclusion: Policies and Attributes Needed
    1. patient privacy policy, application policy, resource (data protection) policy
    2. subject attributes, resource attributes, activity attributes, context/purpose attributes, patient attributes
    3. Binding of policies and attributes (and attribute sources)

Generic Access Control Model for Federated Healthcare Networks

  1. Extension and Refinement of the Generic Model (Chapter 1)
    1. additional Patient Domain
    2. 2 flavours of the resource domain:
      1. resource domain
      2. application domain
    3. each domain controls attributes and policies
    4. each domain may exist with none, one, or multiple instances
  2. Identification and Authentication
    1. Subject Authentication (XUA)
    2. Role Attributes and Role Activation
    3. Patient Identification
  3. Privacy Policy Activation and Session Control
    1. Context Activation
    2. Application Policy Selection
    3. Privacy Policy Selection
    4. Separation of DAC- and RBAC-style rules
    5. Policy Decision and Enforcement (Context Domain)
    6. Policy Decision and Enforcement (App Domain)
  4. Resource Control
    1. Resource Policy Selection
    2. Patient Privacy Policy Push vs. Pull
    3. Resource Attribute Retrieval
    4. Policy Decision and Enforcement
  5. Actors and Transactions
    1. Security Token Services, Policy Registries and Policy Repositories, Attribute Services (Directories), PEP and PDP
    2. Security Token Retrieval, Policy Retrieval, Attribute Retrieval, Role Activation, Policy Decision and Enforcement
    3. Management Interfaces

Sample Adaptations of the Generic Model

  1. XSPA Actor Deployment and Flow of Control
  2. Regional Healthcare Network Based on IHE XDS/XUA
  3. Distributed EHR Based on IHE XDS/XCA/XUA
  4. eCR Security Architecture [under construction]
  5. BPPC with context-side/resource-side PEP [under construction]

Methodology for Tailoring the Generic Model

  1. Introduction
  2. Policy Determination and Permission Catalogue
    1. Protection Demands (Session Control vs. Resource Control)
    2. Policy Authorities
    3. Policy Paradigms
    4. Identification of Attribute Stubs
    5. Policy Assignment (Indexing for Retrieval)
  3. Attribute Management
    1. Classification of Attribute Stubs
    2. Domain Assignment
    3. Policy Assignment
    4. Specification of Attribute Value Sources
  4. Policy Management
    1. Protection Granularity (Permissions)
    2. Policy Encoding
    3. Policy Deployment
  5. Access Control Systems within the Domains
    1. PEP/PDP Placement
    2. Authorization Request Interface
    3. Policy Retrieval (Pull/Push)
    4. Attribute Retrieval (Pull/Push)
  6. Integration of the ACSs into the Application Control Flow
    1. Session Management (if required)
    2. Mapping of Resource Requests onto Authorization Requests
    3. Security Token Control Flow
  7. Policy Lifecycle Management

Standards for Implementing the Actors and Transactions of the Generic Model

  1. Layering Opportunities (Message Header, SOAP Header, SOAP Body)
  2. Security Token Encoding and Exchange
    1. SAML and WS Trust
    2. Subject authentication and subject attribute exchange based on XUA (protection token)
    3. Encoding and exchange of policy references and policies as security tokens (supporting token)
  3. Policy Encoding
    1. XACML
  4. Attribute Management and Attribute Retrieval
    1. PWP, PDQ, ...

Appendix A: Glossary of Terms

Appendix B: Standards and Vocabularies for Attribute Names and Values


Standards and Specs to be considered

SAML

Any information on policies that is to be exchanged is encoded as a SAML 2.0 assertion. The respective profiling must be in line with the conventions defined for XUA. The use of WS Trust RST/RSTR is prefered for the SAML 2.0 protocol.

WS Trust

Issuing and validation of SAML-encoded security token is performed by WS Trust STS. The experiences made with the eCR implementations based on the SUN and Microsoft WS Trust frameworks should be considered in order to avoid WS Trust features that are not implemented in a compatible manner by these platforms.

XSPA

XSPA is the reference model with respect to the building blocks and the flow of control.

XACML

Anything specified in the white paper must be implementable using XACML encoded policies.



References

IHE IT Infrastructure White Paper: HIE Security and Privacy through IHE Profiles. Version 2.0, August 22, 2008. (PDF)


Detailed proposal

Access control white paper detailed proposal