ITI Access Control White Paper: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
JohnMoehrke (talk | contribs)
No edit summary
 
(51 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 98: 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
##[[ACWP_Motivation|Motivation]]
<p>
###Privacy and Data Security
== Access Control in Healthcare ==
###Access Control vs. Perimeter Protection
#[[ACWP_Motivation|Motivation]] <font color=red>[2nd draft, open issues pending]</font>
###Needs-to-Know Principle
#[[ACWP_Typical_AC_Scenarios_in_Healthcare|Access Control Scenarios in Healthcare]] <font color=red>[2nd draft, open issues pending]</font>
##Typical Access Control Use Cases in Healthcare
#[[ACWP_Objective_and_Outline|Objective and Outline of the White Paper]] <font color=red>[2nd draft, ToC missing]</font>
##State of the Art
 
###Paradigms: DAC, MAC, RBAC, ...
== Fundamentals of Access Control ==
###Policy Based Access Control (PEP, PDP, ...)
#[[ACWP_Chapter2_Intro|Chapter Intro]] <font color=red>[1st draft, ready for review]</font>
###Standards (SAML, WS*, XACML, XSPA, ...)
#[[ACWP_State_of_the_Art|State of the Art]] <font color=red>[2nd draft, open issues pending]</font>
##Challenge
##Principles of Secure Design
###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?
##Common Access Control Models
###Multiple policy sources and specific workflow aspects add another layer of complexity
##Policy Based Access Control
###But: Things must be kept simple to be safe and efficient
#[[ACWO_SOA_Security|SOA Security Principles]] <font color=red>[2nd draft]</font>
##Generic Model for Access Control (based on XSPA)
#[[ACWP_Generic_Model_for_AC|Access Control System]] <font color=red>[2nd draft]</font>
###Access Control System within each domain
##Building blocks
###Attribute Management (Directories and Services)
##Access Control Domains
###Context Domain
####Issuer of a request affecting a protected resource
####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 (PIX, 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
###Automatted workflows
##The role of the “Purpose”  
###The role of the “Purpose”  
##Instantiation of access rights for organizations
###Instantiation of access rights for organizations
#[[WPAC_Resource_Security_RBAC|Resource Security through Role Based Access Control]]
##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
###client-side vs. resource-side enforcement
##Opt-Out considered harmful
###Prefetching of patient data
##client-side vs. resource-side enforcement
###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)
#Generic Access Control Model for Federated Healthcare Networks
 
##Extension and Refinement of the Generic Model (Chapter 1)
== Generic Access Control Model for Federated Healthcare Networks ==
###additional Patient Domain
#Extension and Refinement of the Generic Model (Chapter 1)
###2 flavours of the resource domain:
##additional Patient Domain
####resource domain
##2 flavours of the resource domain:
####application domain
###resource domain
###each domain controls attributes and policies
###application domain
###each domain may exist with none, one, or multiple instances
##each domain controls attributes and policies
##Identification and Authentication
##each domain may exist with none, one, or multiple instances
###Subject Authentication (XUA)
#Identification and Authentication
###Role Attributes and Role Activation
##Subject Authentication (XUA)
###Patient Identification
##Role Attributes and Role Activation
##Privacy Policy Activation and Session Control  
##Patient Identification
###Context Activation
#Privacy Policy Activation and Session Control  
###Application Policy Selection
##Context Activation
###Privacy Policy Selection
##Application Policy Selection
###Separation of DAC- and RBAC-style rules
##Privacy Policy Selection
###Policy Decision and Enforcement (Context Domain)
##Separation of DAC- and RBAC-style rules
###Policy Decision and Enforcement (App Domain)
##Policy Decision and Enforcement (Context Domain)
##Resource Control
##Policy Decision and Enforcement (App Domain)
###Resource Policy Selection
#Resource Control
###Patient Privacy Policy Push vs. Pull
##Resource Policy Selection
###Resource Attribute Retrieval
##Patient Privacy Policy Push vs. Pull
###Policy Decision and Enforcement
##Resource Attribute Retrieval
##Actors and Transactions
##Policy Decision and Enforcement
###Security Token Services, Policy Registries and Policy Repositories, Attribute Services (Directories), PEP and PDP
#Actors and Transactions
###Security Token Retrieval, Policy Retrieval, Attribute Retrieval, Role Activation, Policy Decision and Enforcement
##Security Token Services, Policy Registries and Policy Repositories, Attribute Services (Directories), PEP and PDP
###Management Interfaces
##Security Token Retrieval, Policy Retrieval, Attribute Retrieval, Role Activation, Policy Decision and Enforcement
#Sample Adaptations of the Generic Model
##Management Interfaces
##XSPA Actor Deployment and Flow of Control
 
##Regional Healthcare Network Based on IHE XDS/XUA
== Sample Adaptations of the Generic Model ==
##Distributed EHR Based on IHE XDS/XCA/XUA
#XSPA Actor Deployment and Flow of Control
##eCR Security Architecture
#Regional Healthcare Network Based on IHE XDS/XUA
##BPPC with context-side/resource-side PEP
#Distributed EHR Based on IHE XDS/XCA/XUA
#Methodology for Tailoring the Generic Model
#[[eCR Security Architecture]] <font color=red>[under construction]</font>
##Policy Determination
#[[BPPC with context-side/resource-side PEP]] <font color=red>[under construction]</font>
###Session Control vs. Resource Control
 
###Policy Authorities
== Methodology for Tailoring the Generic Model ==
###Paradigms for Patient Privacy Policy, App Policy, Resource Policy
#[[ACWP_Methodology_Introduction|Introduction]]
###Policy Assignment (Indexing for Retrieval)
#Policy Determination and Permission Catalogue
##Attribute Identification
##Protection Demands (Session Control vs. Resource Control)
###Identification of Attribute Stubs
##Policy Authorities
###Domain Assignment
##Policy Paradigms
###Policy Assignment
##Identification of Attribute Stubs
###Specification of Attribute Value Sources
##Policy Assignment (Indexing for Retrieval)
##Policy Management
#[[ACWP_Methodology_Attribute_Management|Attribute Management]]
###Policy Encoding
##Classification of Attribute Stubs
###Policy Deployment
##Domain Assignment
##Access Control Systems within the Domains
##Policy Assignment
###PEP/PDP Placement
##Specification of Attribute Value Sources
###Policy Retrieval (Pull/Push)
#Policy Management
###Attribute Retrieval (Pull/Push)
##Protection Granularity (Permissions)
###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
#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 ==





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