Скачать презентацию CS 290 C Formal Models for Web Software Скачать презентацию CS 290 C Formal Models for Web Software

f0d69d9180d04ed58985407adaea0f64.ppt

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

CS 290 C: Formal Models for Web Software Lecture 10: Web. Alloy: Website Modeling, CS 290 C: Formal Models for Web Software Lecture 10: Web. Alloy: Website Modeling, Analysis and Synthesis with Alloy Instructor: Tevfik Bultan

Access Control for Web Applications • Access control in web applications is a crucial Access Control for Web Applications • Access control in web applications is a crucial problem • Web applications handle a wide variety of critical data – Ecommerce sites store customer account information and purchase history – Online applications for taxes, permits, visas – Google Health, Microsoft Health. Vault allow patients to upload their medicate data online and share it with doctors and hospitals

Access Control • Access control in web applications is difficult – Access control mechanisms Access Control • Access control in web applications is difficult – Access control mechanisms provided by file systems, databases or web servers are too coarse grain – Manual coding of the access control mechanisms in scripting languages is error prone – Web application frameworks do not provide many options for customized access control • There have been high profile information leaks: – Harvard Business School website was leaking admission status from a URL before the official notification – Website for payroll processing let 25 K customers to access each others’ W 2 forms • Both of these leaks were due to improper enforcement of the access control policy

Observation • In a typical web application, any operation has to be specified in Observation • In a typical web application, any operation has to be specified in multiple contexts: – The application logic implementing the action – The security layer enforcing the access control policy – The user interface that initiates the action • The idea in Web. Alloy is to specify the operations and related access control rules once as part of the data model and then automatically generate the implementation

Website Modeling with Weballoy • Recall that in Alloy signatures denote as set of Website Modeling with Weballoy • Recall that in Alloy signatures denote as set of objects (atoms) • For example, a data model for an online grades management can be specified with the following signatures: abstract sig User { } sig Teacher, Student extends User { } sig Course { } • In addition to user defined signatures, Weballoy supports the following signatures: – Int, Bool, String, Date. Time, Email, and Password

Fields • Relationships among objects are specified as fields of signatures abstract sig User Fields • Relationships among objects are specified as fields of signatures abstract sig User { name: String, } sig Teacher extends User { teaches: set Course } sig Student extends User { assists, attends: set Course } sig Course { name: String, teachers: set Teacher, assistants, students: set Student, grades: students -> lone Int }

Alloy Metamodel • Every Alloy model corresponds to an instance of the Alloy metamodel Alloy Metamodel • Every Alloy model corresponds to an instance of the Alloy metamodel – each signature s in the original model corresponds to a meta atom denoted as s$ – each field f in the signature s corresponds to a meta atom denoted s$f • Given a meta atom m for a signature – m. fields denotes the set of meta atoms that correspond to the fields of that signature – m. value denotes the elements in that signature • Given a meta atom m for a field – m. value denotes the tuples in that field

Alloy metamodel • Behaviors of a model can be specified reflectively using the metamodel Alloy metamodel • Behaviors of a model can be specified reflectively using the metamodel pred equal [c 1, c 2: Course] { c 1. name = c 2. name c 1. teachers = c 2. teachers c 1. assistants = c 2. assistants c 1. students = c 2. students c 1. grades = c 2. grades } pred equal [c 1, c 2: Course] { all f: Course$. fields | c 1. (f. value) = c 2. (f. value) } • The expression Course$. fields denotes the set of meta atoms corresponding to fields in the Course signature

Facts • The allowed behavior of the data model can be restricted using facts Facts • The allowed behavior of the data model can be restricted using facts fact { teachers = ~teaches } • This fact denotes that the teachers and teaches relations are exactly the inverse of each other

Transactions • Weballoy supports transactions for modifying the data model • Transactions allow adding Transactions • Weballoy supports transactions for modifying the data model • Transactions allow adding atoms to a signature, destroying atoms, adding tuples to a field and removing tuples from a field. • Modifications to the data model are grouped into transactions – Each transaction is either executed as a whole or rejected as a whole • Each transaction consists of – a set of atoms and tuples to be added and – a set of atoms and tuples to be deleted

Transactions • Each transaction is defined as a pair of sets (AS, DS): – Transactions • Each transaction is defined as a pair of sets (AS, DS): – AS is the set of atoms and tuples to be added – DS is the set of atoms and tuples to be deleted • For each (m, x) pair in AS – Either m is a meta atom denoting a signature and x is a fresh atom to be added to that signature – Or m is a meta atom denoting a field and x is a new tuple to be added to that field • Each (m, x) pair in DS is also either a signature or a field

Transactions • Example transaction – the first set is the AS, and the second Transactions • Example transaction – the first set is the AS, and the second set is the DS ({ // AS (Course$, c 2), (Course$name, c 2 ->"Software Engineering"), (Course$teachers, c 2 ->t 1) }, { // DS (Course$, c 1) } )

Queries • Each query RS is a set of pairs (x, f) where – Queries • Each query RS is a set of pairs (x, f) where – x is an atom and – f is a meta atom corresponding to a field of x that the user wants to retrieve • The following queries retrieve – The set of courses taught by t 1 – The set of teachers teaching c 1 { (t 1, Teacher$teaches), (c 1, Course$teachers) }

Preconditions • Preconditions specify conditions that must be evaluated before an atom is created Preconditions • Preconditions specify conditions that must be evaluated before an atom is created or destroyed or before a tuple is inserted or removed. • Precondition on creating an atom for a given signature s can be specified by declaring a predicate: s. pre. Add • Precondition on adding a tuple to a given field f can be specified by declaring a predicate: f. pre. Add

Preconditions • In a predicate f. pre. Add, the default parameter is this • Preconditions • In a predicate f. pre. Add, the default parameter is this • The parameter this corresponds to the tuple (v 1 ->v 2) being added to the f field. – It contains two values v 1 and v 2, one for the domain of the relation and one for the range of the relation – this. first returns v 1 – this. second returns v 2

Preconditions • In a precondition, it is also possible to refer to a singleton Preconditions • In a precondition, it is also possible to refer to a singleton set called me – me corresponds to the current logged-in user’s atom – If the user is not logged in, me evaluates to empty set

Preconditions • Examples – A user cannot add teaching assistants to a course if Preconditions • Examples – A user cannot add teaching assistants to a course if the user is not teaching that course – A user cannot remove a teaching assistant from a course if the user is not the teacher nor the teaching assistant being removed pred assistants. pre. Add { (one me) and (me in this. first. teachers) } pred assistants. pre. Del { (one me) and (me in this. first. teachers + this. second) }

Postconditions • Postcondition on creating an atom for a given signature s can be Postconditions • Postcondition on creating an atom for a given signature s can be specified be declaring a predicate: s. post. Add • Postcondition on adding a tuple to field f can be specified by declaring a predicate: f. post. Add

Postconditions • Examples: – A newly created course has exactly one teacher and no Postconditions • Examples: – A newly created course has exactly one teacher and no assistants nor students. – Last teacher of a course cannot be removes pred Course. post. Add { this. teachers = me one this. teachers no this. assistants + this. students } pred teachers. post. Del { some this. first. teachers }

Expansion Triggers • A mechanism for automatically propagating changes in one field to other Expansion Triggers • A mechanism for automatically propagating changes in one field to other fields • Given field f and g the user can declare “f. on. Add: g” to denote that set of tuples should be automatically added to g when f grows fun fun teachers. on. Add: teaches teachers. on. Del: teaches. on. Add: teachers teaches. on. Del: teachers { { this. second -> -> this. first } }

Expansion triggers • Expansion triggers can also propagate changes between a field and a Expansion triggers • Expansion triggers can also propagate changes between a field and a signature or between a two signatures: – A. on. Add: f : denotes the set of tuples to add to f whenever A grows – A. on. Del: f : denotes the set of tuples to remove from f when A shrinks – f. on. Del: A : denotes the set of atoms to delete from A whenever f shrinks – A. on. Del: B : denotes the set of atoms to delete from B whenever A shrinks

Capabilities • Each capability is a triple: Action->univ • Actions are: R (retrieval), A Capabilities • Each capability is a triple: Action->univ • Actions are: R (retrieval), A (addition), D (deletion) • There are five types of capabilities: – Atom creation – Atom deletion – Tuple insertion – Tuple deletion – Tuple retrieval

Capabilities • Creating a new atom in signature s requires the capability tuple (A, Capabilities • Creating a new atom in signature s requires the capability tuple (A, A, s$) • Destroying an existing atom x requires the capability triple (D, D, x) • Inserting the tuple (x 1, x 2, …, xn) into field f in signature s requires the capability triple (A, x 1, s$f) • Deleting the tuple (x 1, x 2, …, xn) from field f in signature s requires the capability triple (D, x 1, s$f) • Reading the tuple (x 1, x 2, …, xn) from field f in signature s requires the capability triple (R, x 1, s$f) – Reading capabilities are ignore when processing a transaction

Capabilities • Weballoy defines the following default functions for convinience: – ADD = A-> Capabilities • Weballoy defines the following default functions for convinience: – ADD = A-> A – DELETE = D->D – W = A+D – RW = R+W enum Action { R, A, D } fun W: Action { A + D } fun RW: Action { R + W } fun ADD: Action->Action { A -> A } fun DELETE: Action->Action { D -> D }

Access control policies using Capabilities • Access control policies can be specified using capabilities Access control policies using Capabilities • Access control policies can be specified using capabilities • Instead of writing capabilities for each field separately, meta model can be used to write concise access control policies: fun policy: Action -> univ { W -> me. teaches -> Course$. fields }

Example • Given the policy: fun policy: Action -> univ { W -> me. Example • Given the policy: fun policy: Action -> univ { W -> me. teaches -> Course$. fields } • Suppose teacher t 1 wishes to remove s 1 from c 1. assistants where the current database is as follows: Teacher = t 1 + t 2 + t 3. Student = s 1 + s 2 + s 3. Course = c 1 + c 2 + c 3. c 1. assistants = s 3. c 2. assistants = s 1. c 3. assistants = s 2. t 1. teaches = c 1 + c 2. teaches = c 3. teaches = c 1.

Example • The capabilities possessed by t 1 are determined by evaluating the policy Example • The capabilities possessed by t 1 are determined by evaluating the policy function with me = t 1. • The expression me. teaches evaluates to {c 1, c 2}, so t 1 currently has 20 capability triples resulting from the cross product {A, D} → {c 1, c 2} → {Course$name, Course$teachers, Course$assistants, Course$students, Course$grades}. • The required capability D → c 1 → Course$assistants is one of the 20 capabilities currently possessed by t 1, so the request is approved if it does not violate another constraint such as a pre- or post-condition.

Processing a Transaction • When a transaction is received, the server does the following: Processing a Transaction • When a transaction is received, the server does the following: – Check the capability rules and make sure that the user has the required capability – Check the preconditions for the atom creation and tuple insertion requests and applies the on. Add triggers, performs creations & insertions and then checks the postconditions – If any pre or post conditions are violated, then the entire transaction is rejected – If a fact is violated all changes are rolled back and the transaction is rejected.

Processing a Query • When a query is received, it is not necessary to Processing a Query • When a query is received, it is not necessary to evaluate pre or postconditions since the data model is not being modified • When a query is received, the website associates the singleton set me with the atom corresponding to the user making the query (or empty set if the user is not logged in) and then evaluates the capability function policy to determine the capabilities possessed by the user.

Validation • Using Alloy as a specification language has the significant benefit: – The Validation • Using Alloy as a specification language has the significant benefit: – The model can be automatically validated • The Alloy run command can be used to generate instances of the data model • Alloy check command can be used to do bounded verification

Validation Example • Check whether the pre-condition for adding an assistant to a course Validation Example • Check whether the pre-condition for adding an assistant to a course is true if and only if the current user possesses the corresponding capability triple for adding assitants: check { all c: Course, s: Student | pre. Add[c->s] iff A->c->Course$assistants in policy }

module Weballoy sig Date = Int {} sig Date. Time = Int {} sig module Weballoy sig Date = Int {} sig Date. Time = Int {} sig Email = String {} sig Password = String {} sig Long. String = String { } lone sig me in univ { } abstract sig Entity { name: lone String, owners: set Entity, created: Date. Time, modified: Date. Time, } abstract sig Named. Entity extends Entity { } { some name } abstract sig Login. User extends Named. Entity { suspended: Bool, email: disjoint Email, password: Password } enum Action { R, A, D } fun W: fun RW: fun ADD: fun DELETE: Action->Action { D -> D } Action{A+D} Action{R+W} Action->Action { A -> A } fun first [x: univ->univ] : univ { x. univ } fun second [x: univ->univ] : univ { univ. x } Weballoy library specifications

Web Application Synthesis • Weballoy automatically generates web application implementations from Alloy specifications written Web Application Synthesis • Weballoy automatically generates web application implementations from Alloy specifications written based on the approach we discussed in the previous slides • The synthesized application consists of – Java. Script client code – Java servlets running on the server – A custom-made relational tuple store is used as the database

Web Application Synthesis • The automatically generated code consists of – Database schema automatically Web Application Synthesis • The automatically generated code consists of – Database schema automatically generated from the Alloy data model using Weballoy schema compiler – Java. Script +HTML code automatically generated from the Alloy data model using the Weballoy AJAX compiler – Servlets automatically generated from the Alloy access control specification using the Weballoy policy compiler

Web application synthesis • The front-end Java. Script and the back-end server code are Web application synthesis • The front-end Java. Script and the back-end server code are decoupled and communication by sending RPC messages via HTTP POST – There are five message types supported for communication between the client and the server • When the user makes changes, the Java. Script code combines the set of additions and deletions by the user to a transaction and sends it to the server – The transaction request is checked by the write capability checker, the insertion checker, the deletion checker and the consistency checker before the changes are committed to the data store

Message Types • There are five RPC message types used for client and server Message Types • There are five RPC message types used for client and server side communication – Login: Returns an authentication cookie – Logout: Invalidates an existing cookie – Get: Returns a set of tuples – Suggest: Returns a set of atoms whose field values start with a given substring – Submit: Submits a transaction

Front-End Customization Using Templates • Weballoy generates a default user interface • This default Front-End Customization Using Templates • Weballoy generates a default user interface • This default user interface can be customized by the user • Weballoy has a template system that allows embedding of Alloy expressions in HTML • denotes a field element which is displayed using the built-in widget designed for that field’s type – means use the view labeled v • displays each atom of the signature –

Templates sig Message { author: String, subject: String, text: Long. String, replies: set Reply Templates sig Message { author: String, subject: String, text: Long. String, replies: set Reply } sig Reply { author: String, text: String } Author: Subject: Text: Replies: Author: Text:

Author: Subject: Author: Subject: Templates Author: Subject: Text: wrote ""