A View Based Security Framework for XML

1. A View Based Security Framework for XML Wenfei Fan, Irini Fundulaki, Floris Geerts, Xibei Jia, Anastasios Kementsietsidis University of Edinburgh Digital Curation Center

2. Introduction • XML data management • The importance is clearly demonstrated by the wide adoption of XML related technologies in eScience projects • Selective exposure of information in XML • a primary concern for data providers, curators and consumers. • safeguard data confidentiality, privacy and intellectual property

3. Introduction --- Security View • Security View: multiple user groups • who wish to query the same XML document • different access policies may be imposed, specifying the portions of the document the users are granted or denied access to. • Security views are necessarily virtual • it is prohibitively expensive to materialize and maintain a large number of views.

4. Example: a medical records XML database Hospital Psychiatry Genetics Record Record Record Date Doctor Patient Bill Date Patient Doctor Date Bill Patient Doctor Bill Diagnosis Name Name Sex Diagnosis Sex Name Sex Name Diagnosis Name Name 'Mary' 'David' 'David' 'Mary' 'Mark'' 'Angela' Patient “Mary” can access his own medical records Doctor “David” can only access the records of his patients The security admin could see the whole db

5. Insurer’s view An insurer can only read his customers' billing info

6. Researcher’s View a medical researcher could retrieve the diagnosis data for research purposes, but not the information on doctors or patients.

7. Security Spec. Editor XML document System Architecture researchers security admins legend input module View Query Security Result output module Editor Specification S Derivation Viewer core module D Query Q optional module R R on V Security Security R Security virtual view View V View V View V D P R XML schema for Query for for ... Role U Role U Role U XML database Rewriting D P R with with with XML data flow XSD D XSD D XSD D D P R other data flow Query Q T on T XSD D for security spec. lang. LS Query document T used by admins. Evaluation T view spec. lang. LV transparent to users. Indexer view query lang. LQV used by users. Query Optimization doc query lang. LQR transparent to users.

8. Security Specification • hospital -> patient* • (hospital,patient) = [visit/treatment/medication = ‘autism’] • patient -> pname, visit*, parent* • (patient,pname) = N • (patient,visit) = N • parent -> patient • visit -> treatment, date • (visit, treatment) = [medication] • treatment -> test + medication • (treatment,test) = N

9. Security Specification • Classify the nodes in the XML document • accessible nodes • inaccessible nodes • conditional accessible nodes • Support • inheritance • overriding • content-based access privilege • context-dependency • View derivation module • schema availability • the availability of an XML schema that specifies the structure of accessible data is critical to the users who can then formulate queries only over this schema.

10. View Specification • hospital -> patient* • (hospital, patient) = patient[visit/treatment/medication = ‘autism’] • patient -> treatment*, parent* • (patient, treatment) = visit/treatment[medication] • (patient, parent) = parent • parent -> patient • (parent, patient) = patient • treatment -> medication • (treatment, medication) = medication

11. Query Over the View • Regular XPath Query • a mild extension of XPath that supports the general Kleene closure (.)* instead of the limited recursion “//”. • Why: XPath is not closed under query rewriting • i.e. for an XPath query on a recursively defined view there may not exist an equivalent XPath query on the underlying document

12. Query Over the Document • Regular XPath Query • However, the size of the rewritten query QT, if directly represented in Regualar XPath, may be exponential in the size of input query QV. • We overcome this challenge by employing an automaton characterization of QT ,denoted by MFA(mixed finite state automata), which is linear in the size of QV. • Query Rewriting Module

13. MFA: Internal Query Representation hospital/patient[(parent/patient)*/visit/treatment/test and visit/treatment[medication/text()=“headache”]]/pname

14. Query Evaluation: HyPE • We propose a novel algorithm, HyPE (Hybrid Pass Evaluation), for processing Regular XPath queries represented by MFA’s. • A unique feature of HyPE is that it needs only a single top-down depth-first traversal of the XML tree, during which HyPE both • evaluates predicates of the input query (equivalently, AFA's of the MFA) and • identifies potential answer nodes (by evaluating the NFA of the MFA). • previous systems require to traverse the XML document at least twice to evaluate XPath queries.

15. HyPE: Cans (candidate answers) • The potential answer nodes are collected and stored in an auxiliary structure, referred to as Cans (candidate answers), which is often much smaller than the XML document tree. • A pass over Cans is needed to retrieve the real result nodes.

16. HyPE

17. SMOQE: A Reference Implementation • We have developed a reference implementation, called SMOQE(Secure MOdular Query Engine), for the security framework we proposed in this paper. • It is implemented in Java. • demonstrated in VLDB 2006

18. Conclusion • A generic, flexible view based access control framework for protecting XML data and its implementation: SMOQE • able to enforce fine-grained access policies according to the structure and values of the protected XML data • schema availability • view derivation • efficient enforcement of security constraints during XML query evaluation • Query rewriting • Automaton based representation • Evaluation using HyPE and optimization

19. Thank you!