Difference between revisions of "ITI Access Control White Paper"

From IHE Wiki
Jump to navigation Jump to search
 
(40 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 =
Line 41: 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 ]]
Line 100: Line 101:
 
'''Note:''' Some of the level-2-headings provide links to text blocks and figures on the respective topic
 
'''Note:''' Some of the level-2-headings provide links to text blocks and figures on the respective topic
 
<p>
 
<p>
−
== 1. Access Control: Motivation and State-of-the-Art ==
+
== Access Control in Healthcare ==
−
#[[ACWP_Motivation|Motivation]] <font color=red>[1st draft ready for review]</font>
+
#[[ACWP_Motivation|Motivation]] <font color=red>[2nd draft, open issues pending]</font>
−
##Privacy and Data Security
+
#[[ACWP_Typical_AC_Scenarios_in_Healthcare|Access Control Scenarios in Healthcare]] <font color=red>[2nd draft, open issues pending]</font>
−
##Access Control vs. Perimeter Protection
+
#[[ACWP_Objective_and_Outline|Objective and Outline of the White Paper]] <font color=red>[2nd draft, ToC missing]</font>
−
##Needs-to-Know Principle
+
 
−
#[[ACWP_Typical_AC_Scenarios_in_Healthcare|Typical Access Control Scenarios in Healthcare]] <font color=red>[1st draft ready for review]</font>
+
== Fundamentals of Access Control ==
−
#[[ACWP_State_of_the_Art|State of the Art]] <font color=red>[under construction]</font>
+
#[[ACWP_Chapter2_Intro|Chapter Intro]] <font color=red>[1st draft, ready for review]</font>
 +
#[[ACWP_State_of_the_Art|State of the Art]] <font color=red>[2nd draft, open issues pending]</font>
 
##Principles of Secure Design
 
##Principles of Secure Design
−
##Paradigms: DAC, MAC, RBAC, ...
+
##Common Access Control Models
−
##Policy Based Access Control (PEP, PDP, ...)
+
##Policy Based Access Control
−
##Standards (SAML, WS*, XACML, XSPA, ...)
+
#[[ACWO_SOA_Security|SOA Security Principles]] <font color=red>[2nd draft]</font>
−
#[[ACWP_Generic_Model_for_AC|Generic Model for Access Control (based on XSPA)]] <font color=red>[under construction]</font>
+
#[[ACWP_Generic_Model_for_AC|Access Control System]] <font color=red>[2nd draft]</font>
−
##Access Control System within each domain
+
##Building blocks
−
##Management of Attributes and Policies
+
##Access Control Domains
−
##Context Domain
+
##Federated Healthcare Environments
−
##Subject Domain (in XSPA part of the issuing domain)
+
##IHE Profiles
−
##Resource Domain
 
−
#Objective and Outline of this Paper
 
−
##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
 
  
−
== 2. Specific Requirements of Federated Healthcare Networks ==
+
== Policies and Attributes ==
−
#Federated Healthcare Environments
 
−
##Trust Brokerage and Security Token
 
−
##Federation of the Resource Domain (XCA)
 
−
##Federated Identities within the Subject Domain (XUA)
 
−
##Distributed Patient Attributes (PIX, XCPI)
 
 
#Session Control vs. Resource Control
 
#Session Control vs. Resource Control
 
##Granularities and flavours of protected resources
 
##Granularities and flavours of protected resources
Line 134: Line 126:
 
##Instantiation of access rights for organizations
 
##Instantiation of access rights for organizations
 
#[[WPAC_Resource_Security_RBAC|Resource Security through Role Based Access Control]]
 
#[[WPAC_Resource_Security_RBAC|Resource Security through Role Based Access Control]]
 +
##Needs-to-Know Principle
 
##HL7 role engineering
 
##HL7 role engineering
 
##Role activation
 
##Role activation
 
##HL7/VA access control matrices
 
##HL7/VA access control matrices
−
#The Role of the Patient
+
#[[WPAC_The Role of the Patient|The Role of the Patient]]
 
##Patient Privacy Policies (Consents)
 
##Patient Privacy Policies (Consents)
 
##DAC-style vs. RBAC-style PPPs
 
##DAC-style vs. RBAC-style PPPs
 +
##Opt-Out considered harmful
 
##client-side vs. resource-side enforcement
 
##client-side vs. resource-side enforcement
−
##Prefetching of patient data
 
 
##patient-bound tokens (e. g. EHCs) as access control measures
 
##patient-bound tokens (e. g. EHCs) as access control measures
−
#Conclusion: Policies and Attributes Needed
+
#[[WPAC_Conclusion_Policies_and_Attributes|Conclusion: Policies and Attributes Needed]]
 
##patient privacy policy, application policy, resource (data protection) policy
 
##patient privacy policy, application policy, resource (data protection) policy
 
##subject attributes, resource attributes, activity attributes, context/purpose attributes, patient attributes
 
##subject attributes, resource attributes, activity attributes, context/purpose attributes, patient attributes
 
##Binding of policies and attributes (and attribute sources)
 
##Binding of policies and attributes (and attribute sources)
  
−
== 3. Generic Access Control Model for Federated Healthcare Networks ==
+
== Generic Access Control Model for Federated Healthcare Networks ==
 
#Extension and Refinement of the Generic Model (Chapter 1)
 
#Extension and Refinement of the Generic Model (Chapter 1)
 
##additional Patient Domain
 
##additional Patient Domain
Line 177: Line 170:
 
##Management Interfaces
 
##Management Interfaces
  
−
== 4. Sample Adaptations of the Generic Model ==
+
== Sample Adaptations of the Generic Model ==
 
#XSPA Actor Deployment and Flow of Control
 
#XSPA Actor Deployment and Flow of Control
 
#Regional Healthcare Network Based on IHE XDS/XUA
 
#Regional Healthcare Network Based on IHE XDS/XUA
 
#Distributed EHR Based on IHE XDS/XCA/XUA
 
#Distributed EHR Based on IHE XDS/XCA/XUA
−
#eCR Security Architecture
+
#[[eCR Security Architecture]] <font color=red>[under construction]</font>
−
#BPPC with context-side/resource-side PEP
+
#[[BPPC with context-side/resource-side PEP]] <font color=red>[under construction]</font>
  
−
== 5. Methodology for Tailoring the Generic Model ==
+
== Methodology for Tailoring the Generic Model ==
−
#Policy Determination
+
#[[ACWP_Methodology_Introduction|Introduction]]
−
##Session Control vs. Resource Control
+
#Policy Determination and Permission Catalogue
 +
##Protection Demands (Session Control vs. Resource Control)
 
##Policy Authorities
 
##Policy Authorities
−
##Paradigms for Patient Privacy Policy, App Policy, Resource Policy
+
##Policy Paradigms
 +
##Identification of Attribute Stubs
 
##Policy Assignment (Indexing for Retrieval)
 
##Policy Assignment (Indexing for Retrieval)
−
#Attribute Identification
+
#[[ACWP_Methodology_Attribute_Management|Attribute Management]]
−
##Identification of Attribute Stubs
+
##Classification of Attribute Stubs
 
##Domain Assignment
 
##Domain Assignment
 
##Policy Assignment
 
##Policy Assignment
 
##Specification of Attribute Value Sources
 
##Specification of Attribute Value Sources
 
#Policy Management
 
#Policy Management
 +
##Protection Granularity (Permissions)
 
##Policy Encoding
 
##Policy Encoding
 
##Policy Deployment
 
##Policy Deployment
−
#Access Control Systems within the Domains
+
#[[ACWP_Methodology_ACS_Domains|Access Control Systems within the Domains]]
 
##PEP/PDP Placement
 
##PEP/PDP Placement
 +
##Authorization Request Interface
 
##Policy Retrieval (Pull/Push)
 
##Policy Retrieval (Pull/Push)
 
##Attribute Retrieval (Pull/Push)  
 
##Attribute Retrieval (Pull/Push)  
−
##Authorization Request Interface
 
 
#Integration of the ACSs into the Application Control Flow
 
#Integration of the ACSs into the Application Control Flow
 
##Session Management (if required)
 
##Session Management (if required)
Line 209: Line 205:
 
#Policy Lifecycle Management
 
#Policy Lifecycle Management
  
−
== 6. Standards for Implementing the Actors and Transactions of the Generic Model ==
+
== Standards for Implementing the Actors and Transactions of the Generic Model ==
 
#Layering Opportunities (Message Header, SOAP Header, SOAP Body)
 
#Layering Opportunities (Message Header, SOAP Header, SOAP Body)
 
#Security Token Encoding and Exchange
 
#Security Token Encoding and Exchange

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

Retrieved from "http://wiki.ihe.net/index.php?title=ITI_Access_Control_White_Paper&oldid=41251"