Скачать презентацию A Fine-Grained Access Control System for XML Documents Скачать презентацию A Fine-Grained Access Control System for XML Documents

512ca4c643906f819f79ca3923c99430.ppt

  • Количество слайдов: 58

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

Motivation – why access control is needed? An online store – update products prices? 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,

Introduction Different approaches have been proposed that address the problem of protecting information in 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.

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

Introduction Why do we need access control? Introduction Why do we need access control?

Introduction Basic transactions are increasingly realized by exchanging the appropriate digital documents. Document exchange 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!

Introduction - XML focuses on the description of information structure and content as opposed Introduction - 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.

Authorization subjects Authorization subjects

Authorization subjects - Definitions Referred as identities or location where request is originated from. 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: . 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?

Authorization subjects – Example A faculty dean (user=dean) wants to check budgets from his 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.

Authorization subjects – Hierarchy (3. 1) Hierarchy. A triple <X, Y, ≤>, where ≤ Authorization subjects – Hierarchy (3. 1) Hierarchy. A triple , 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 = IP Hierarchy: IPH = Symbolic Name Hierarchy: SNH = Can be pictured as a directed graph, UGH as directed acyclic graph and IPH & SNH as trees.

Authorization subjects - UGH example Public Medical. Stuff Medicine Administrative Pediatrics Phy. C Comp. Authorization subjects - UGH example Public Medical. Stuff Medicine Administrative Pediatrics Phy. C Comp. Stuff. T Phy. P Bob Norse. C Alice Tom Sam

Authorization subjects - IPH & SNH examples * 130. * * 149. *. *. Authorization subjects - IPH & SNH examples * 130. * * 149. *. *. * 200. *. *. * 149. 135. 80. * *. org *. com *. edu *. hospital. com *. cardiology. hospital. com

Authorization subjects - Authorization subject hierarchy (ASH) is a hierarchy <R, SH, ≤>, where Authorization subjects - Authorization subject hierarchy (ASH) is a hierarchy , where R= U x I x S, SH = UG x IP x SN and each triplet ≤ iff ug 1 ≤ ug 2 and ip 1 ≤ ip 2 and sn 1 ≤ sn 2. Example: ≤ This way we will know how to access control definition effects a subject.

Authorization objects Authorization objects

Authorization objects - Definitions A set Obj of uniform resource identifiers (URI) denotes the 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: l 1/l 2/l 3/…/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

Authorization Objects absolute or relative path expression may contain Authorization Objects absolute or relative path expression may contain ". " 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

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

Specifications Specifications

Access authorization basic features Support all levels of granularity, including specific files and elements 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?

Access authorization basic features To a certain documents, or to a certain DTD (document 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.

Access authorization basic features The content specification may coincide with Empty, Any, or with 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.

Authorization types Authorization types

Access Authorization Definition (5. 1) Access Authorization. An access authorization a in Auth is Access Authorization Definition (5. 1) Access Authorization. An access authorization a in Auth is a five-tuple of the form: , 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.

Access Authorization - properties Each access authorization states whether a subject can (or cannot) 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.

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

Compute. View algorithm Given a request from rq to view a certain URI, the Compute. View algorithm Given a request from rq to view a certain URI, the following algorithm first initializes variable T to the tree representing the document and r to the root of T.

Compute. View algorithm Compute. View algorithm

Compute. View - Initial. Label After initialization, the algorithm invokes procedure Initial. Label(T, rq). Compute. View - Initial. Label After initialization, the algorithm invokes procedure Initial. Label(T, rq). The purpose of Initial. Label is to associate authorizations with the corresponding elements/attributes. Then add the subjects to the relevant list (n. veclabel[t]. Denied/Allowed) of each element.

Issues to deals with If a subject belongs to both the denial list of 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. A different approach can be implemented in Set. Label and Nothing takes precedence. then the algorithm will work accordingly.

Compute. View algorithm Compute. View algorithm

Compute. View – Set. Label This behavior is realized by method Set. Label, applied Compute. View – Set. Label This behavior is realized by method Set. Label, applied on all the document nodes in a preorder visit starting from the root r. Set. Label combines, for each type t, the two lists veclabel[t]. Allowed and veclabel[t]. Denied of subjects according to the “most specific subject/denials take precedence” principle.

Compute. View algorithm Compute. View algorithm

Compute. View Get. Final. Label Method Get. Final. Label considers the nodes of T Compute. View Get. Final. Label Method Get. Final. Label considers the nodes of T according to a preorder visit of the tree and propagates permissions/denials associated with a node to its descendants.

Compute. View algorithm Compute. View algorithm

The view can be obtained by pruning from the original document tree all 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 ε.

Compute. View algorithm Compute. View algorithm

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

Access data example Access data example

Example of Access Authorization table Example of Access Authorization table

Hospital’s policy (Organization DTD-level authorizations applicable to all the departments of the hospital). Requirements 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]

Hospital’s policy (Organization DTD-level authorizations applicable to all the departments of the hospital). Information 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]

Hospital’s policy (Organization DTD-level authorizations applicable to all the departments of the hospital). Information 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 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]

Medicine department’s policy. (Site DTD-level authorizations to complement or override the organization DTD-level authorizations). 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]

Medicine department’s policy. (Site DTD-level authorizations to complement or override the organization DTD-level authorizations). 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]

Cardiology division’s policy. (Specified at the instance level to complement or override the hospital’s 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 Nurse. C group. [t]-[u]-[v]

Cardiology division’s policy. (Specified at the instance level to complement or override the hospital’s 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]

Cardiology division’s policy. (Specified at the instance level to complement or override the hospital’s 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 Nurse. C group. [t]-[u]-[v]

Extentions Write support Extentions Write support

Write operations Like read authorizations, write authorizations can be local or recursive, hard or 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.

Write operations < <Phy. C, *, *. hospital. com> , /department[. /@name=`medicine']/patient//therapy[. /cost < Write operations < , /department[. /@name=`medicine']/patient//therapy[. /cost < 10, 000] > , insert, +, R states that members of group Phy. C can insert a new therapy for a patient in the Medicine department, and that the privilege is limited to insertion of therapies whose cost does not exceed $10, 000.

Write operations Updates are evaluated by executing the labeling process on both the existing Write operations Updates are evaluated by executing the labeling process on both the existing document and on the document that results from the execution of the update. If the final label associated with the node being updated is positive in both versions the operation is completed successfully; otherwise it is rejected.

< <Nurse. C, *, *. hospital. com>, /department[. /@name=`medicine']/patient/room/bed [number(value())>=100 and number(value())<=150] , update, < , /department[. /@name=`medicine']/patient/room/bed [number(value())>=100 and number(value())<=150] , update, +, L > This means the subjects in group Nurse. C are thus responsible for updating the distribution of patients in the block, but they are not allowed to transfer patients across blocks.

Software implementation Software implementation

Architectural Requirements From the architectural point of view, a first point to note is Architectural Requirements From the architectural point of view, a first point to note is that our design is fully server side. Seamless integration. Quality of service.

Backup Backup

DTD example DTD example