Secure XML Querying with Security Views Wenfei Fan

Secure XML Querying with Security Views Wenfei Fan University of Edinburgh & Bell Laboratories Chee-Yong Chan National University of Singapore Minos Garofalakis Bell Laboratories 1

The need for XML security Data in XML format: ü Business information: confidential ü Health-care data: Patient Privacy Act, … Access control: ü multiple groups simultaneously query the same XML document ü each user group has a different access-control policy Enforcement of access-control policies: inaccessible user group 1 . . . user group n XML Query Engine 2

Secure XML querying For each user group of an XML document T, ü specify a access-control policy S, ü enforce S: for any query Q posted by the group over the document T, Q(T) consists of only data accessible wrt S Access control for XML: ü How to specify access policies at various levels of granularity? ü How to efficiently enforce those access policies? user group Q inaccessible XML document T Q(T) XML Query Engine 3

Example: an XML document of patients Document DTD D hospital patient* * patient SSN, name, record* record date, diagnosis, treatment * SSN name record treatment (trial + regular) trial tr. Name, treatment* date diagnosis regular tname, bill treatment Access-control policies over docs of D: ü Doctors in the hospital are granted access to all the data in the docs ü Insurance company is allowed to access billing information only trial tr. Name * regular tname DTD graph bill 4

Access-control policy for syndrome surveillance hospital ü patients: accessible to only those * who are diagnosed to have a certain disease “DIS” (a constant) patient * ü records: SSN – only with diagnosis = “DIS” – part of “DIS” records: date, diagnosis, treatment, tname – denied from seeing whether a patient is in a clinical trail or not (trial, regular, tr. Name) – denied from accessing billing information date name diagnosis record treatment trial X tr. Name X regular X tname bill X * 5

Challenge: Access-control specification hospital ü various levels of granularity: restricting access to entire subtrees or specific elements ü conditional access: e. g. , a patient is accessible if and only if it has a descendant diagnosis = “DIS” ü overriding: e. g. , tname overrides the accessibility of its parent regular ü inheritance: e. g. , SSN and name inherit the accessibility of patient * SSN date name diagnosis record treatment trial tr. Name regular tname bill * 6 conditionally accessible

Challenge: access-control enforcement hospital should not imply any drastic degradation in performance Example: an XPath query Q posed by a syndrome surveillance group over a document T //patient[name=`Joe’]//tname * patient * SSN date name diagnosis record treatment ü access control requirement: Q(T) {accessible tname} trial ü enforcement: ensure that – all and only those Joe’s having a descendant diagnosis = “DIS”, – all and only those records with diagnosis = “DIS” tr. Name regular tname bill * 7 conditionally accessible

Challenge: schema availability ü One needs schema information to hospital facilitate query formulation and optimization patient * * ü How to define a schema (DTD) characterizing all and only the accessible information, without security breach? SSN date name diagnosis record treatment ü How to automatically derive such a DTD from the document DTD and an access-control specification? XML DTD is far more complicated than its relational counterpart – recursive, nondeterministic trial tr. Name regular tname bill * 8 conditionally accessible

Previous proposals/standards for XML security Dozens of models have been proposed for XML: XACML, XACL, … ü Specifying and enforcing access-control at a physical level – annotate data nodes in an XML document with accessibility, and check accessibility at runtime (with optimizations for tree-pattern queries and tree/DAG DTDs), or – materialize a view consisting of accessible data Problems: – costly (time, space): multiple accessibility annotations/views – error-prone: integrity maintenance becomes a problem when the underlying data or access policy is updated ü No support for schema availability: either deny access to any schema information, or expose the entire document DTD -- security breach 9

A seemingly plausible model ü annotate data nodes with accessibility hospital * ü check accessibility at runtime, and patient ü expose the document DTD D * Example: permissible XPath queries: SSN name record ü Q 1: //patient[name=`Joe’]/record /treatment/*/tname date diagnosis ü Q 2: //patient[name=`Joe’]/record treatment /treatment//tname Security breach: from the document DTD it follows that if Q 2(T) – Q 1(T) is nonempty then Joe is involved in a clinical trial tr. Name * regular tname bill 10

Our security model for XML ü Security administrator: specifies a access-control policy for each group by extending the document DTD with XPath qualifiers ü Derivation module: automatically derives a security-view definition from each policy: view DTD and mapping via XPath ü Query translation module: rewrite and optimize queries over views to equivalent queries over the underlying document query Security view 1 (view DTD, xpath( )) derivation module specification 1 specification n specification k query Security view k (view DTD, xpath( )) Rewriter Security view n (view DTD, xpath( )) query translation module Optimizer 11 XML document

Overcome the limitations of previous proposals ü Specification and enforcement: at the conceptual (schema) level – no need to update the underlying XML data – no need to materialize views or perform runtime check ü Schema availability: view schema is automatically derived – characterizing accessible data – exposing necessary schema information only query Security view 1 (view DTD, xpath( )) derivation module specification 1 specification n specification k query Security view k (view DTD, xpath( )) Rewriter Security view n (view DTD, xpath( )) query translation module Optimizer 12 XML document

Access-control specification Access policy + Document DTD = XPath qualifiers ü DTD D : element type definitions A : : = PCDATA | | A 1, …, Ak | A 1 + … + Ak | A* ü Specification S = (D, access( )): a mapping access( ) from the edges in the document DTD { Y, N, [q] }. For each A , for each B in , define Access(A, B) as – Y: accessible (true) – N: inaccessible (false) – [q]: XPath qualifier, conditional: accessible iff [q] holds XPath fragment: p : : = q : : = p | | A | p = “c” * | | // | q 1 q 2 p/p | | p p | p[q] q 1 q 2 | q 13

Example: access policy S for syndrome surveillance access(hospital, patient) = [//diagnose = “DIS”] -- [q 1] access(patient, record) = [diagnose = “DIS”] hospital * -- [q 2] patient [q 1] access(treatment, trial) = N * access(treatment, regular) = N SSN record [q 2] name access(regular, tname) = Y ü overriding: if access(A, B) = Y (N), date then the B children of A override the accessibility of A ü inheritance: if access(A, B) is not explicitly defined, then the B children of A inherit the accessibility of A ü content-based: conditional accessibility via XPath qualifiers diagnosis treatment trial tr. Name regular tname bill * 14 conditionally accessible

Properties of the specification language ü XML tree of the document DTD: hospital the accessibility of each data node * is uniquely defined by an access patient [q 1] specification * – relative to the path from root SSN name record [q 2] – a qualifier at a node a constrains the entire subtree date diagnosis treatment rooted at a, e. g. , [q 2] constrains tname regular ü various levels of granularity: entire trial subtrees or specific elements tr. Name ü schema level: the underlying XML tname bill data is not touched; efficient, easy * to specify and maintain 15 conditionally accessible

Enforce access control – security views XML security view: = (Dv, xpath( )) with respect to an access policy S = (D, access( )), ü Dv: view DTD, exposed to the user and characterizing the accessible information (of document DTD D) wrt S Schema availability: to facilitate query formulation ü xpath( ): mapping from instances of D to instances of Dv defined in terms of XPath queries and view DTD Dv – for each A in Dv, for each B in , xpath(A, B) = p – p: generates B children of an A element in a view p : : = q : : = p | | A // | p/p | p p | p[q] | * | p = “c” | q 1 q 2 | q 16

Example: view DTD for syndrome surveillance = (Dv, xpath( )) with respect to access policy S = (D, access( )) hospital * * patient [q 1] patient * SSN name SSN record date diagnosis View DTD Dv diagnosis * tr. Name only treatment trial tname ü Expose accessible information record [q 2] name treatment ü Hide trial, tr. Name, regular, bill * regular tname bill * Document DTD D 17

Example: view definition for syndrome surveillance xpath( ): maps edges in view DTD Dv to paths in document DTD D ü hospital patient* xpath(hospital, patient) = hospital/patient [q 1]: [//diagnose=“DIS”] hospital semantics: • top-down construction • preserving qualifiers in a specification patient SSN name patient record ü patient SSN, name, record* xpath(patient, SSN) = SSN, /* name */ xpath(patient, record) = record [q 2]: [diagnose=“DIS”] 18

DTD-directed construction of security views ü record date, diagnosis, treatment xpath(record, date) = date /* diagnosis, treatment */ hospital patient ü treatment tname* xpath(treatment, tname) = //tname SSN ü DTD-directed construction name date record diagnosis treatment view DTD conformance treatment ü Never materialized the construction strategy is just to give the semantics trial tr. Name * tname regular tname bill 19

Derivation of security-view definition XML security views are far more intriguing than relational views ü multiple XPath queries vs. a single SQL query ü DTD vs. relational schema One needs an algorithm to compute a security-view definition: ü Input: an access policy S = (D, access( )) ü Output: a security-view definition = (Dv, xpath( )) – sound: accessible information only – complete: all the accessible data (structure preserving) – DTD-conformant: conforming to the view DTD ü efficient: O(|S|2) time ü generic: recursive/nondeterministic document DTDs 20

Algorithm: deriving a security-view definition ü Top-down traversal of the document DTD D ü short-cutting/renaming (via dummy) inaccessible element types ü normalizing the view DTD Dv and reducing dummy types xpath(hospital, patient) = hospital/patient[q 1] hospital * patient [q 1] * SSN date name diagnosis treatment * patient xpath(patient, record) = record[q 2] record [q 2] hospital SSN date name diagnosis xpath(record, treatment) = treatment * record treatment 21

deriving a security-view definition ü recursive and non-deterministic productions treatment trial tr. Name * treatment dummy 1 dummy 2 regular tname bill * xpath(treatment, dummy 2) = regular xpath(treatment, dummy 1) = trail ü reducing dummy element types: tname treatment * tname (dummy 1/treatment)* / dummy 2 / tname dummy 2/tname) (dummy 1/treatment)* / dummy 2 / tname* xpath(treatment, tname) = //tname 22

Enforce access control via query rewriting security views are virtual: not materialized ü Efficiency: no extra costs to support multiple security views over the same large document simultaneously ü Consistency/integrity: updating the underlying data introduces no difficulties/overhead Query translation: one needs an efficient algorithm to rewrite queries over a security view to equivalent and efficient queries over the underlying document query Security view k (view DTD, xpath( )) Rewriter Optimizer query translation module XML document 23

algorithm rewrite ü Input: – = (Dv, xpath( )) (security view wrt S = (D, access( ))), and – an XPath query Qv over the view (Dv) ü Output: an equivalent XPath query Qt over the document – for any XML document T of D, Qt(T) = Qv( (T)) Dynamic programming: ü for any subquery Qv’ of Qv, any node A in view-DTD graph Dv rewrite Qv’ at A by incorporating xpath(A, _) Qt’ (A) ü efficient: O(|Qv| | |2 ) time ü a practical class of XPath (with union, descendant, qualifiers) vs. tree-pattern queries studied in previous security models 24

Example: query rewriting for syndrome surveillance Qv = // patient[name=“Joe”] // tname over the view hospital * patient xpath(hospital, patient) [name = “Joe”] / xpath(patient, record) / xpath(record, treatment) / SSN date name diagnosis * record treatment * xpath(treatment, tname) tname hospital * * patient [q 1] SSN date name diagnosis record [q 2] Qt = /hospital/patient[name = “Joe” and //diagnosis = “DIS”] treatment /record[diagnosis = “DIS”] trial tr. Name * regular tname bill /treatment // tname equivalent query over document 25

Query optimization with structural constraints Optimize Qt = rewrite( , Qv) by leveraging the document DTD D Q = A[B] // E[F] //H A [B and C] // H // F[G] / H Q’ = A /B / E / F / H ü A [B and C] empty-set exclusive constraint: an A element cannot have both B and C children at the same time B ü // F[G] / H empty-set non-existence constraint: a F element does not have a G child A C E F G ü A[B] // E[F] // H A /B / E / F / H exclusive constraint: B and C do not coexist under an A element disjunction: exclusive constraints H DTD graph conjunction: existence (nonexistence) 26 constraints

Example: heuristic for XPath containment Q = // *[C] //E // E A Q’ = A /B / E ü Q 1 Q 2 if Q 1 Q 2 // *[C] //E // E B // E A /B / E * heuristic for XPath containment (NP-hard for small fragments in the presence of DTDs) ü image graph: evaluation of sub-queries over DTD graph ü containment test: extension of simulation – Q 1 Q 2 if image(Q 1) is simulated by image(Q 2) [C] – qualifiers: inverse simulation ü effective: preliminary experimental study (speedup up to a factor of 2) C E DTD graph A A B B E image graph for // *[C] //E E image graph 27 for // E

Summary ü security views: the first model for specifying/enforcing XML security at a schema level and providing schema availability – a fine-grained access-control specification language – an effective enforcement framework via security views • view DTD: characterizing accessible information • algorithm for deriving security-view definitions • algorithms for query rewriting/optimization: no need to materialize views or to perform runtime security checks ü future work: – reasoning about security views (soundness, completeness, DTD conformance – subsume XPath satisfiability with DTDs) – inference control in the presence of external knowledge A practical solution for securing XML querying 28