ITI Access Control White Paper

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

This chapter is aimed at motivating the need for flexible access control services in healthcare. It provides some typical use cases and gives an impression on what readers can expect to learn from the white paper. The recent extent is 2.5 pages.

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]

Access Control: State of the Art

1. State of the Art [1st draft, ready for review]
   1. Principles of Secure Design
   2. Access Control Paradigms
   3. Policy Based Access Control
2. SOA Security [1st draft, ready for review]
   1. Decouple Authorization and Authentication
   2. Decouple Security Object Lookup and Use
3. Access Control System [1st draft, ready for review]
   1. Building blocks
   2. Access Control Domains
   3. Federated Healthcare Environments
   4. Existing 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, ...

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