Index

• Virtual Views
• Access Control
• Existing Langs/Tools
  • XACML
• Expressivity
• TODO

Virtual Views

• SPARQL CONSTRUCT can be used to create virtual views.

for more details, see the background slides.

Virtual View Example

   PREFIX :mydb <http://cityhospital.example/dbs>
CONSTRUCT { ?o a          :PatientObservation .
            ?o :patient   ?p .
            ?p foaf:name  ?pName .
            ?p :takes     ?takes .
            ?o :doctor    ?d .
            ?d foaf:name  ?dName }

    WHERE { ?o mydb:patient ?p .
            ?o mydb:doctor  ?d .
            ?d mydb:name    ?dName .
            ?p  mydb:patientName ?pName .
           }

Tailored View Example

   PREFIX :obs <http://cityhospital.example/dbs/observations>
   PREFIX :ppl <http://cityhospital.example/dbs/people>
   PREFIX :med <http://cityhospital.example/dbs/medication>
   PREFIX :acl <http://cityhospital.example/dbs/acls>
CONSTRUCT { ?o a          :PatientObservation .
            ?o :patient   ?p .
            ?p foaf:name  ?pName .
            ?p :takes     ?takes .
            ?o :doctor    ?d .
            ?d foaf:name  ?dName }

    WHERE { ?o obs:patient ?p .
            ?o obs:doctor  ?d .
            ?d ppl:name    ?dName .
            OPTIONAL {
               ?p   ppl:familyName ?pName .
               ?acl acls:entitles  ?_requester .
	       ?acl acls:includes  acls:identity
            }
            OPTIONAL {
               ?p   obs:medication ?takes .
	       ?acl acls:entitles  ?_requester .
	       ?acl acls:includes  acls:medication
            }

       GRAPH <users> {
	?_requestor
		x:username $USER ;
		x:ip       $IP ;
       }
          }

from protocol

Tailored View Query

SELECT    { ?o :patient   ?p .
            ?p :takes     ?takes .
            ?o :doctor    ?d .
            ?d :foaf:name "Dr. Bob"
          }

Tailored Views

• Different approaches: view-based solutions are more desirable
• Filters can limit view to subset allowed for a given user.
• Preprocessing of the query
• Access control policy may be edited indepedently

Existing Langs/Tools

• XACML, XML language for communicating principles and privileges
• Ponder2,
• X-RBAC, XML Role Based Access Control
• KAoS, Agent Oriented Systems
• Rei, OWL Based Security Policy Specification

XACML

• wide deployment
• covers use cases like who has access to what patient data
• commercial (Parthenon, AX2E) and open source (Sun, XACML Enterprise, Herasaf) implementations
• health care profile leans on HL7 permissions

Expressivity

Specific endowment language
Read or write a particular field.

Roles for describing endowments in large strokes
PrimaryCarePhysician implies access to medical history.

Rules extending endowments
Radiologist at accredited clinic implies access to X-ray corpus.

Obligations
Doctor must not deliver medical history to third parties.

Deployments

Product Integration

XACML Example

XACML Example

	<Policy PolicyId="Policy0" RuleCombiningAlgId="Permit-Overrides">
	<Description>Sales Report Policy</Description>

	<Target/>

	<Rule RuleId="Report_Access" Effect="Permit">
      	 <Target>
		<Subjects> 
      	      <Subject>		Manager         </Subject>     
		</Subjects>

		<Resources>  
	  	  <Resource>	Sales Report      </Resource> 
		</Resources>

		<Actions>  
      	      <Action>		Modify         </Action>  
		</Actions>
      	 </Target>
	       <Condition>
		<SubjectAttributeDesignator AttributeId="Division“/> 
   	      	 <AttributeValue> Sales Department </AttributeValue>  
	      </Condition>
	</Rule>

	<Rule RuleId="FinalRule" Effect="Deny"/>

	</Policy>
	

Cross Entrprise Security and Privacy Authorizations (XSPA) Profile

• addresses Security Considerations
• specifies the use of NIST Electronic Authentication Guideline and Liberty Identity Access Framework
• maps HL7 requirements as XACML attributes (M and O)
• recommends SAML profile of XACML for communication

XACML Healthcare Usecase for XSPA
(Permissions on Data Roles)

Request in RDF

@prefix xacml: <urn:oasis:names:tc:xacml:2.0:context:schema:os> .
@prefix subject1: <urn:oasis:names:tc:xacml:1.0:subject:> .
@prefix subject2: <urn:oasis:names:tc:xacml:2.0:subject:> .
@prefix hl7-subject: <urn:oasis:names:tc:xspa:1.0:subject:hl7:> .
@prefix hl7-resource: <urn:oasis:names:tc:xspa:1.0:resource:hl7:> .
@prefix hl7-xspa: <urn:oasis:names:tc:xspa:1.0:hl7:> .
@prefix resource: <urn:oasis:names:tc:xacml:1.0:resource:> .
@prefix env: <urn:oasis:names:tc:xspa:1.0:environment:> .

<> doc:schemaLocation 
"urn:oasis:names:tc:xacml:2.0:context:schema:os
     http://docs.oasis-open.org/xacml/
		access_control-xacml-2.0-context-schema-os.xsd" .
	

[ a xacml:Request ;
 xacml:Subject [
   subject1:subject-id "Dr. Bob" ;
   subject1:locality "Facility A" ;
   subject2:role "physician" ;
   hl7-subject:permission
               hl7-xspa:prd-006 ,
               hl7-xspa:prd-010 ;
   subject2:purpose "Healthcare Treatment" .
 ] ;
 xacml:Resource [
   resource:resource-id "Bambi Smith" ;
   hl7-resource:type hl7-resource:medical-record .
 ] ;
 env:locality "Facility A" .
] .


	

Enforcement by SPARQL extension functions

FILTER( x:UBA_notExcludes_subject($p, "Bob") &&   # protocol
        x:UBA_notExcludes_role($p, <physician>) &&
        (/* MA? */) && 
        x:data_includes(?p, <P_006>) &&     # CONSTRUCT rule
        x:data_includes(?p, <P_010>) &&     # CONSTRUCT rule
        x:locality_includes(?p, "192.168.1.1") && # protocol
        x:role_includes(?p, <physician>) )

Enforcement by graph constraints

WHERE { ?o mydb:patient ?p .
        ?o mydb:doctor  ?d .
        ?d mydb:name    ?dName .
        ?p  mydb:patientName ?pName .
	GRAPH <policies> { ?p x:data includes "identity" }
        ?p  mydb:medication ?takes .
  	GRAPH <policies> { ?p x:data includes "medication" }
        GRAPH <users> {
	  _:requestor
		x:username "Bob" ;
		x:ip       "192.168.1.1" ;
        }
      }

Scenario

proof tools

• generation
• validation
• browsing

HCLS Task Forces

• COI - injection into the query transform.
• Terminology - controlled vocabularies for parts of shared graphs (persona).
• Pharma Ontology - use cases may warrant access controls

Tailored View Example

   PREFIX :obs <http://cityhospital.example/dbs/observations>
   PREFIX :ppl <http://cityhospital.example/dbs/people>
   PREFIX :med <http://cityhospital.example/dbs/medication>
   PREFIX :acl <http://cityhospital.example/dbs/acls>
CONSTRUCT { ?o a          :PatientObservation .
            ?o :patient   ?p .
            ?p :foaf:name ?pName .
            ?o :doctor    ?d .
            ?d :foaf:name ?dName }

    WHERE { ?o obs:patient ?p .
            ?o obs:doctor  ?d .
            ?d ppl:name    ?dName .
        OPTIONAL {
            ?p  ppl:familyName ?pName .
	    ?acl acls:entitles ?_requester .
	    ?acl acls:includes acls:identity
        }
        OPTIONAL {
            ?p  obs:medication ?takes .
	    ?acl acls:entitles ?_requester .
	    ?acl acls:includes acls:medication
        }

       GRAPH <users> {
	?_requestor
		x:username $USER ;
		x:ip       $IP ;
       }
          }

from protocol

policy injection from XACML

<foo> a xacml:Policy ;
    xacml:pair [
      xacml:pattern
        "{
           ?a  ppl:familyName ?b .
         }" ;
      xacml:covers hl7:identity ] ;
    xacml:pair [
      xacml:pattern
        "{
           ?a  obs:medication ?b .
         }" ;
      xacml:covers hl7:medication ] .
	

Steps for HCLS Task Forces

• Security needs for given use cases.
• Protocol points for enforcement.
• ??Expression and delegation language??