A Fine-Grained Access Control System for XML Documents

1. A Fine-Grained Access Control Systemfor XML Documents Presented by: Daniel Moran &Marina Yatsina ERNESTO DAMIANI Universit `a di Milano SABRINA DE CAPITANI DIVIMERCATI Universit `a di Brescia STEFANO PARABOSCHI Politecnico di Milano and PIERANGELA SAMARATI Universit `a di Milano

2. Motivation – why access control is needed? • An online store – update products prices? Insert new products? Buy products? • Working with source control – who has permissions to change which files? • A site for reviewing services/products/art – The creator can’t see the rating,

3. Introduction • Different approaches have been proposed that address the problem of protecting information in a Web system, but these approaches typically operate at the file-system level. • Part of this problem is due to the limitations of HTML, historically used to design Web documents.

4. Agenda • Introduction. • Authorization subjects. • Authorization objects. • Specifications. • Usage example. • Extensions. • Software implementation.

5. Introduction Why do we need access control?

6. Introduction • Basic transactions are increasingly realized by exchanging the appropriate digital documents. • Document exchange on the Internet should meet precise security requirements involving data units at the level of granularity stipulated by the communicating parties. • HTML doesn’t satisfy these requirements!

7. Introduction - XML • XML focuses on the description of information structure and content as opposed to its presentation. • XSL (XML style language) is a standard for expressing how XML-based data should be rendered. • Our goal is by exploiting XML’s own capabilities to define and implement an authorization model for regulating access to XML documents.

8. Authorization subjects

9. Authorization subjects - Definitions • Referred as identities or location where request is originated from. • The model we are presenting support both. • Each request subject is presented by a triplet: <user-id,IP-address,sym-address>. • To support sets of users & sets of machines the model support users-group and location patterns. Question: why do we need both IP and symbolic name?

10. Authorization subjects – Example • A faculty dean (user=dean) wants to check budgets from his work-laptop (sym-name=dean-laptop) from home (ip=192.168.1.3). • Same dean wants to give funds to a professor in the faculty, this time from his office: user=dean, sym-name=dean-laptop, ip=132.68.46.1.

11. Authorization subjects – Hierarchy (3.1) Hierarchy. A triple <X,Y, ≤>, where ≤ is a partial order on Y. and X is a set of the minimal elements of Y with respects to the partial order. • Users groups Hierarchy: UGH = <U, UG, ≤> • IP Hierarchy: IPH = <I, IP, ≤> • Symbolic Name Hierarchy: SNH = <S, SN, ≤> Can be pictured as a directed graph, UGH as directed acyclic graph and IPH & SNH as trees.

12. Authorization subjects - UGH example

13. Authorization subjects - IPH & SNH examples

14. Authorization subjects - Authorization subject hierarchy Authorization subject hierarchy (ASH) is a hierarchy <R, SH, ≤>, where R= U x I x S, SH = UG x IP xSN and each triplet <ug1,ip1,sn1> ≤ <ug2,ip2,sn2> iff ug1 ≤ ug2 and ip1 ≤ ip2 and sn1 ≤ sn2. Example: <Alice, 149.135.80.3, s1.hospital.com> ≤ <Medicine, 149.135.*.* , *.com> This way we will know how to access control definition effects a subject.

15. Authorization objects

16. Authorization objects - Definitions A set Obj of uniform resource identifiers (URI) denotes the resources to be protected. In XML documents, URI can be path expressions using the XPath language. Path expression: a sequence of elements name (or predefined functions) separated by ‘/’ character: l1/l2/l3/…/ln. Path expression may terminate with attribute name, which is distinguished by preceding them with ‘@’ character. XPath Functions also can be used. Examples: /department/medical_stuff/physician

17. Authorization Objects • absolute or relative • path expression may contain "." or ".." or "//" • /department//leader • path expressions may also include functions • The name of a function and its arguments are separated by a double colon “::”. • research/ancestor::department • ps/attribute::xlink:href • /department/child::medical staff//city

18. A URI to protect prices of products would look like: /breakfast_menu/food/price Suppose we would have also tags of <drink> under menu, and we want to protect all prices, what would be the path expression then? /breakfast_menu//price Authorization objects – Examples

19. Specifications

20. Access authorization basic features • Support all levels of granularity, including specific files and elements within them. • Authorizations can be either positive (permissions) or negative (denials). • Authorizations can be supplied either locally or with recursive approach. Question: why both positive and negative?

21. Access authorization basic features • To a certain documents, or to a certain DTD (document type definition). A DTD may include declarations for elements, attributes, entities, and notations.

22. Access authorization basic features • The content specification may coincide with Empty, Any, or with a group of one or more subelements/groups. • Declarations of sequence and choices of subelements also describe the subelements’ cardinality; • Allow users to specify instance-level authorizations as soft and DTD-level authorizations as hard.

23. Authorization types

24. Access Authorization Definition (5.1) Access Authorization. An access authorization a in Auth is a five-tuple of the form: <subject, object, action, sign, type>, where: • subject is a member of ASH. • object is a URI in Obj, or URI:PE (PE = Path expression). • action = read/update/insert/delete. • sign= +/- (allow/deny). • type = LDH, RDH, L, R, LD, RD, LS, RS.

25. Access Authorization - properties • Each access authorization states whether a subject can (or cannot) access an element/attribute (or set of them). • The type associated with each authorization on a given object determines the “behavior” of the authorization with respect to the object structure. • Since authorizations can be of different levels (instance vs. schema), strength (hard vs. soft), and propagation (local vs. recursive), we associate with each node n an array,n.veclabel.

26. One element authorizations data • n.veclabel[t].sign = +/-/ε • n.veclabel[t].Denied, n.veclabel[t].Allowedare 2 lists storing all the subjects having positive/negative authorization of type t that applies to n.

27. ComputeView algorithm • Given a request from rq to view a certain URI, the following algorithmfirst initializes variable T to the tree representing the document and r to the root of T.

28. ComputeView algorithm

29. ComputeView - InitialLabel After initialization, the algorithm invokes procedure InitialLabel(T,rq). The purpose of InitialLabel is to associateauthorizations with the corresponding elements/attributes. Then add the subjects to the relevant list (n.veclabel[t].Denied/Allowed) of each element.

30. Issues to deals with If a subject belongs to both the denial list of an element and its allowed list, what should the authorization be? • Most specific subject takes precedence. • Denials take precedence. • Permissions take precedence. • Nothing takes precedence. A different approach can be implemented in SetLabel and then the algorithm will work accordingly.

31. ComputeView algorithm

32. ComputeView – SetLabel This behavior is realized by method SetLabel, applied on all the document nodes in a preorder visit starting from the root r. SetLabel combines, for each type t, the two lists veclabel[t].Allowedand veclabel[t].Deniedof subjects according to the “most specific subject/denials take precedence” principle.

33. ComputeView algorithm

34. ComputeView - GetFinalLabel • Method GetFinalLabel considers the nodes of T according to a preorder visit of the tree and propagates permissions/denials associated with a node to its descendants.

35. ComputeView algorithm

36. The view can be obtained by pruning from the original document tree all the subtrees containing only nodes labeled negative or undefined. • This pruning is enforced by method Prune, which executes a postorder visit on the document tree and removes any leaf labeled - or ε.

37. ComputeView algorithm

38. ComputeView result • The pruned document may be not valid with respect to the DTD referenced by the original XML document. When can it happen?

39. Access data example

40. Example of Access Authorization table

41. Hospital’s policy (Organization DTD-level authorizations applicable to all the departments of the hospital). Requirements expressed as “must” specify statements that do not allow exceptions (which translate to hard authorizations). • Department and division names are publicly accessible. [a]-[b]

42. Hospital’s policy (Organization DTD-level authorizations applicable to all the departments of the hospital). • Information about the name and home address of medical staff and of patients must be accessible to the members of Administrative group connected from domain *.hospital.com.[c]-[d]

43. Hospital’s policy (Organization DTD-level authorizations applicable to all the departments of the hospital). • Information about the salary of the medical staff and the cost of the therapy of all patients of the hospital must be accessible to the members of group Administrative connected from host 159.101.80.5. [e]-[f] • Everybody else must be explicitly forbidden access to this information.[g]-[h]

44. Medicine department’s policy. (Site DTD-level authorizations to complement or override the organization DTD-level authorizations). • Information about medical staff working in the Medicine department with exception of their salary and home address, is publicly accessible. [i]-[j]-[k]

45. Medicine department’s policy. (Site DTD-level authorizations to complement or override the organization DTD-level authorizations). • Information about patients hospitalized in a given division is accessible only to the physicians working in the same division. [m]-[n] Information about the research activity of the Medicine’s divisions is accessible only to the medical staff of the hospital. [o]-[p]

46. Cardiology division’s policy. (Specified at the instance level to complement or override the hospital’s and department’s policy) • Information about “private” projects of the Cardiology division is accessible to the physicians working in the Cardiology division when connected from network 159.*. [q] • No one else can access information about “private” projects. [r] • Information about patients’ illnesses is accessible to nurses of the Cardiology division unless otherwise stated at the DTD level. [s] • Information about name, drug, and room of patients hospitalized in the Cardiology division is accessible to the members of NurseC group. [t]-[u]-[v]

47. Cardiology division’s policy. (Specified at the instance level to complement or override the hospital’s and department’s policy) • Information about “private” projects of the Cardiology division is accessible to the physicians working in the Cardiology division when connected from network 159.*. [q] • No one else can access information about “private” projects. [r]

48. Cardiology division’s policy. (Specified at the instance level to complement or override the hospital’s and department’s policy) • Information about patients’ illnesses is accessible to nurses of the Cardiology division unless otherwise stated at the DTD level. [s] • Information about name, drug, and room of patients hospitalized in the Cardiology division is accessible to the members of NurseC group. [t]-[u]-[v]

49. Extentions Write support

50. Write operations • Like read authorizations, write authorizations can be local or recursive, hard or soft, and can be specified on elements/attributes within either single XML documents or DTDs. • The operations on the node can be insert the node, delete the node, and update the node. Each of these is a distinct write priviledge.