Get documents about "IHE ITI White Paper on Authorization - PowerPoint
Document Sample
IHE ITI White Paper on Authorization
Volume 1 Rough Cut
Outline
Jörg Caumanns, Raik Kuhlisch, Oliver Pfaff, Olaf Rode,
Christof Strack, Heiko Lemke
Berlin, 22.12.08
1
Editing Team
Authors: Raik Kuhlisch, Jörg Caumanns // Fraunhofer ISST
Oliver Pfaff, Markus Franke // Siemens IT Solutions
// and Services
Christof Strack, Heiko Lemke // SUN Microsystems
Supervisior: Rob Horn // Agfa Healthcare
Editorial Team: John Moehrke // GE Healthcare
Lynn Felhofer
Manuel Metz // GIP-DMP
2
Schedule
06. Jan Internal Face-to-Face Meeting (ISST, Siemens)
07. Jan Internal Online Meeting (ISST, Siemens, SUN)
08. Jan Preparation of Slides/Paper for the Editorial Team
09. Jan Online Meeting with Editorial Team (19.00 MEZ)
14. Jan Update of Initial Paper for Internal Discussion
16. Jan Internal Online Meeting (ISST, Siemens, SUN, ELGA)
19. Jan Deadline for Internal Comments
20. Jan Preparation of the Initial Paper for the Editorial Team
21. Jan Online Meeting with Editorial Team (16.00 MEZ)
24. Jan Update of Initial Paper and Preparation of ITI Technical Committee
26.-29. Jan Face-to-Face Meeting with ITI Technical Committee
3
Storyline of the White Paper
• 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.
4
Outline
1. Access Control: Motivation and State-of-the-Art
2. Specific Requirements of Federated Healthcare Networks
3. Generic Access Control Model for Federated Healthcare Networks
4. Methodology for Tailoring the Generic Model
5. Sample Adaptations of the Generic Model
6. Standards for Implementing the Actors and Transactions of the Generic Model
7. Appendix: Glossary of Terms
8. Appendix: Standards and Vocabularies for Attribute Names and Values
5
Chapter 1: Access Control – Motivation and State of the Art
Motivation
• Privacy and Data Security
• Needs-to-Know Principle
State of the Art
• Paradigms: DAC, MAC, RBAC, ...
• Policy Based Access Control (PEP, PDP, ...)
• Standards (SAML, WS*, XACML, XSPA, ...)
Challenge
• 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
6
Chapter 1: Access Control – Motivation and State of the Art
Generic Model for Access Control (based on XSPA)
• Access Control System within each domain
• Attribute Management (Directories and Services)
Domain 1: Context Domains
• Issuer of a request affecting a protected resource
• Management of context attributes
• control of the assertion/message flow
Domain 2: Subject Domain (in XSPA part of the issuing domain)
• Subject authentication
• Management of subject attributes
Domain 3: Resource Domain
• management of protected resources (e. g. data base)
• management of resource attributes
• management of resource security policies
• policy enforcement and policy decision
7
Generic Model (distributed XSPA)
Context Domain Subject Domain
context attributes ACS ACS subject attributes
STS STS Attribute Svc.
role activation PEP / PDP Identity Prv.
request initiator
ACS resource attributes
STS org. security policy
PEP / PDP
resource
Resource Domain 8
Chapter 2: Specific Requirements of (Federated) Healthcare
Networks
Federated Healthcare Environments
• Trust Brokerage and Security Token
• Federation of the Resource Domain (XCA)
• Federated Identities within the Subject Domain (XUA)
• Distributed Patient Attributes (XCPI)
Session Control vs. Resource Control
• Granularities and flavours of protected resources
• The role of the “Purpose”
• Instantiation of access rights for organizations
Resource Security through Role Based Access Control
• HL7 role engineering
• Role activation
• HL7/VA access control matrices
9
Chapter 2: Specific Requirements of (Federated) Healthcare
Networks
The Role of the Patient
• Patient Privacy Policies (Consents)
• DAC-style vs. RBAC-style PPPs
• client-side vs. resource-side enforcement
• patient-bound tokens (e. g. EHCs) as access control
measures
Conclusion: Policies and Attributes Needed
• patient privacy policy, application policy, resource (data
protection) policy
• subject attributes, resource attributes, activity attributes,
context/purpose attributes, patient attributes
• Binding of policies and attributes (and attribute sources)
10
Access Control Layering in Healthcare
application contexts
medication acute care (purpose-driven)
record record
electronic
health record e-prescription
management
session control
(DAC-style)
federated
healthcare infrastructure
resource control
(RBAC-style)
medical resources
(data-centric)
11
Session Control
• In (distributed) medical treatment scenarios, access to medical data is legitimated by
a purpose which is implemented by a medical application
• It is the patient’s right to decide who may act on his data for which purpose. This is
reflected by patient-granted admission rights for the corresponding medical services.
• Examples for admission rights:
• Person A and Organization B may access my EHR
• Any physician to whom I handle over my EHC may
access my medication record
• Admission control is often implemented in a service-specific way; e.g.:
• EHC tickets to access a patient’s e-prescriptions
• eCR admission codes to access a patient’s case record
12
Resource Control
• The objective of resource control is to grant permissions (for operations on object
types) to only the persons who need these permissions in order to perform their
dedicated functional roles within a medical workflow
• Resource control rights reflect the separation of concerns within an organization and
are a measure of data security
• Example for a resource control access right system:
• HL7 healthcare scenario roadmap
• Resource access rights can best be expressed using role-based policies.
Nevertheless most existing hospital information systems use hard-coded access
rules and proprietary permission hierarchies...
13
Chapter 3: Generic ACS Model for Federated Healthcare Networks
Extension and Refinement of the Generic Model (Chapter 1)
• additional Patient Domain
• 2 flavours of the resource domain:
– resource domain
– application domain
• each domain controls attributes and policies
• each domain may exist with none, one, or multiple
instances
14
4-Domain Model (distributed XSPA)
Context Domain Subject Domain
context attributes ACS ACS subject attributes
STS STS Attribute Svc.
role activation PEP / PDP Identity Prv.
request initiator
consent activation ACS ACS resource attributes
STS STS org. security policy
patient privacy PEP / PDP
policy (consent)
resource
Patient Domain Resource Domain 15
5-Domain Model (distributed XSPA)
Subject Domain
Context Domain
ACS subject attributes
context attributes ACS STS Attribute Svc.
Identity Prv.
STS
role activation PEP / PDP
request initiator
ACS application attributes
STS app. security policy
PEP / PDP
consent activation ACS
STS
patient privacy
policy (consent)
Application Domain
Patient Domain
ACS resource attributes
STS org. security policy
PEP / PDP 16
resource
Resource Domain
Chapter 3: Generic ACS Model for Federated Healthcare Networks
Identification and Authentication
• Subject Authentication (XUA)
• Role Attributes and Role Activation
• Patient Identification
Privacy Policy Activation and Session Control
• Context Activation
• Application Policy Selection
• Privacy Policy Selection
• Separation of DAC- and RBAC-style rules
• Policy Decision and Enforcement (Context Domain)
• Policy Decision and Enforcement (App Domain)
17
Chapter 3: Generic ACS Model for Federated Healthcare Networks
Resource Control
• Resource Policy Selection
• Patient Privacy Policy Push vs. Pull
• Resource Attribute Retrieval
• Policy Decision and Enforcement
Actors and Transactions
• Security Token Services, Policy Registries and Policy
Repositories, Attribute Services (Directories), PEP and
PDP
• Security Token Retrieval, Policy Retrieval, Attribute
Retrieval, Role Activation, Policy Decision and
Enforcement
• Management Interfaces
18
Chapter 4: Methodology
Policy Determination
• Session Control vs. Resource Control
• Policy Authorities
• Paradigms for Patient Privacy Policy, App Policy, Resource Policy
• Policy Assignment (Indexing for Retrieval)
Attribute Identification
• Identification of Attribute Stubs
• Domain Assignment
• Policy Assignment
• Specification of Attribute Value Sources
Policy Management
• Policy Encoding
• Policy Deployment
19
Chapter 4: Methodology
Access Control Systems within the Domains
• PEP/PDP Placement
• Policy Retrieval (Pull/Push)
• Attribute Retrieval (Pull/Push)
• 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
20
Core Methodology No Defaults:
AuthZ Model (DAC, MAC, RBAC, ...),
App Request Attr. Types/Sources
App Config AuthZ Request
Defaults:
Syntax of policies
e. g. XACML
PDP
Policy Evaluation ACS
PolicyFinder Runtime
Query (XACML Policy (Set)ID, Target, ...)
Tooltime
3. Policy Deployment Policy Svc Management
2. Policy building by given syntax Policy
1. Define Attributes (Desired Values)
Configuration
Attribute Subject
Attribute Value
Stubs Source ¬ Subject
e .g. Org. Type (Resource,App)
Internal External
ID Datatype (Aut/SSO) (Classes) 21
Chapter 5: Sample Adaptations of the Generic Model
XSPA Actor Deployment and Flow of Control
Regional Healthcare Network Based on IHE XDS/XUA
Distributed EHR Based on IHE XDS/XCA/XUA
eCR Security Architecture
BPPC (Context Domain Enforcement vs. Resource Domain Enforcement)
22
4-Domain Model (XSPA control flow)
Context Domain Subject Domain
1
context attributes ACS 6 ACS subject attributes
5 STS STS Attribute Svc.
role activation PEP / PDP
2 Identity Prv.
request initiator
3 9
4
consent activation ACS 7 ACS resource attributes
STS STS org. security policy
patient privacy PEP / PDP
policy (consent) 8 10 11
resource
Patient Domain Resource Domain 23
Chapter 6: Standards
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, ...
24
Appendix A: Glossary of Terms
Resource Something of value in a network infrastructure to which
rules or policy criteria are first applied before access
is granted [RFC 2753]
Subject Identified and authenticated entity (e. g. a human actor)
who wants to access a resource
Policy Set of rules to administer, manage, and control access
to [network] resources [RFC 3060]
Condition Representation of the necessary state and/or prerequi-
sites that define whether a policy rule’s actions should
be performed [RFC 3198]
25
Appendix B: Standards and Vocabularies for Attribute Names and
Values
Subject Attributes
• Administrative Roles
• Functional Roles
• Organizational Memberships
• Organization Types
Patient Attributes (if anything but the ID is needed at all)
Context Attributes
• Purpose
• Date and Time
Application Attributes (if anything but the ID is needed at all)
Resource Attributes
• Resource Type
26
