access control for health applications ehi connecting communities forum april 11, 2006 don grodecki...
TRANSCRIPT
Access Control for Health Applications
EHI Connecting Communities Forum
April 11, 2006
Don Grodecki
Browsersoft, Inc.
2
OpenHRE
• Open Source Health Records Exchange– http://openhre.org
• Open Source software toolkit for building a Health Records Exchange within a RHIO and between RHIOs
• Developed by Browsersoft Inc.– http://browsersoft.com
3
OpenHRE
• Used to build SHARE for the Alliance for Rural Community Health (ARCH) in Mendocino California– http://ruralcommunityhealth.org
• Used by the Mendocino HRE for the Markle Connecting for Health (CfH) Record Locator Service (RLS) project.– http://mendocinohre.org
– http://www.connectingforhealth.org
4
OpenHRE
• Used by the Mendocino HRE for the ONC NHIN Prototype project, as part of the CSC/CfH team.– http://www.hhs.gov/healthit
5
OpenHRE
• Consists of three main services:– Record Locator Service (RLS)– Record Exchange Service (RES)– Authentication and Access Control Service
(AACS)• We will concentrate here on the AACS
6
Current Practice
• Role-Based Authorization• Users are assigned one or more Roles• Access to information and operations is
controlled by Role• That’s about it!
7
Access Control in OpenHRE
• Access to information and operations controlled by:– IP Address
– Role
– Group
– Information Content
• Security Policies expressed in XACML– OASIS eXtensible Access Control Markup Language
12
Allowed IP Addresses
• Users must access via an IP Address that is within one of the specified ranges.
• If no IP Addresses are specified, then the user can access from anywhere, but, as we shall see, we can limit their access permissions.
13
Groups• Orthogonal to Roles• Groups can have allowed IP Addresses• Coming in via a different IP temporarily removes the User from a Group
16
Rule Details
• Rules Permit or Deny an Action on a Resource to Individuals or Groups
• A Rule’s Resources are a subset of its Role’s Resources
17
Implementation• The Admin web application creates XACML files that
describe the policies it supports, including the details input by the user.
• Directed by the generated XACML, Sun’s XACML interpreter examines the supplied data and grants or denies permission.– http://sunxacml.sourceforge.net
• Policies outside of what is possible using the Admin app can be specified by editing the XACML directly.
18
XACML Examples• This fragment specifies that permission will be granted if
the user has the “read” Action.<Rule RuleId="CommitRule" Effect="Permit"> …
<Action>
<ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType=“.../XMLSchema#string">read</AttributeValue>
<ActionAttributeDesignator DataType=“.../XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0:action: action-id"/>
…
</Rule>
19
XACML Examples• This fragment specifies that “read” will be granted if the resource-
id matches “clinic2” and the User is in the “MC2” Group:<Rule RuleId="read:...:clinic2” Effect="Permit">
…
<ResourceMatch MatchId=”...:function:regexp-string-match">
<AttributeValue>DNS:Arch.org://OTHER:/clinic2/</AttributeValue>
<ResourceAttributeDesignator AttributeId=”...:resource-id" />
…
<ActionMatch MatchId=”...:function:string-equal">
<AttributeValue>read</AttributeValue>
…
<Condition FunctionId=”...:string-is-in">
<AttributeValue DataType=”...#string">MC2</AttributeValue>
<SubjectAttributeDesignator AttributeId=”...:group"/>
…