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	-	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

1. Access Control: Motivation and State-of-the-Art

1. Motivation [1st draft, ready for review]
   1. Privacy and Data Security
   2. Access Control vs. Perimeter Protection
   3. Needs-to-Know Principle
2. Typical Access Control Scenarios in Healthcare [1st draft, ready for review]
3. State of the Art [1st draft, ready for review]
   1. Principles of Secure Design
   2. Paradigms: DAC, MAC, RBAC, ...
   3. Policy Based Access Control (PEP, PDP, ...)
4. Generic Model for Access Control (based on XSPA) [under construction]
   1. Access Control System within each domain
   2. Management of Attributes and Policies
   3. Context Domain
   4. Subject Domain (in XSPA part of the issuing domain)
   5. Resource Domain
5. Objective and Outline of this Paper [under construction]
   1. 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?
   2. Multiple policy sources and specific workflow aspects add another layer of complexity
   3. But: Things must be kept simple to be safe and efficient

2. Specific Requirements of Federated Healthcare Networks

1. Federated Healthcare Environments
   1. Trust Brokerage and Security Token
   2. Federation of the Resource Domain (XCA)
   3. Federated Identities within the Subject Domain (XUA)
   4. Distributed Patient Attributes (PIX, XCPI)
2. 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
3. Resource Security through Role Based Access Control
   1. HL7 role engineering
   2. Role activation
   3. HL7/VA access control matrices
4. The Role of the Patient
   1. Patient Privacy Policies (Consents)
   2. DAC-style vs. RBAC-style PPPs
   3. client-side vs. resource-side enforcement
   4. Prefetching of patient data
   5. patient-bound tokens (e. g. EHCs) as access control measures
5. 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)

3. 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

4. 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
5. BPPC with context-side/resource-side PEP [under construction]

5. Methodology for Tailoring the Generic Model

1. Policy Determination
   1. Session Control vs. Resource Control
   2. Policy Authorities
   3. Paradigms for Patient Privacy Policy, App Policy, Resource Policy
   4. Policy Assignment (Indexing for Retrieval)
2. Attribute Identification
   1. Identification of Attribute Stubs
   2. Domain Assignment
   3. Policy Assignment
   4. Specification of Attribute Value Sources
3. Policy Management
   1. Policy Encoding
   2. Policy Deployment
4. Access Control Systems within the Domains
   1. PEP/PDP Placement
   2. Policy Retrieval (Pull/Push)
   3. Attribute Retrieval (Pull/Push)
   4. Authorization Request Interface
5. 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
6. Policy Lifecycle Management

6. 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