We survey recent work on the specification of an access control mechanism in
a collaborative environment. The work is presented in the context of the
WebdamLog language, an extension of datalog to a distributed context. We
discuss a fine-grained access control mechanism for intentional data based on
provenance as well as a control mechanism for delegation, i.e., for deploying
rules at remote peers.Comment: Proceedings of the 14th International Symposium on Database
  Programming Languages (DBPL 2013), August 30, 2013, Riva del Garda, Trento,
  Ital

Abiteboul, Serge

Antoine, Émilien

Miklau, Gerome

Moffitt, Vera Zaychik

Stoyanovich, Julia

English

arXiv

International audienceWe survey recent work on the specification of an access control mechanism in a collaborative environment. The work is presented in the context of the WebdamLog language, an extension of datalog to a distributed context. We discuss a fine-grained access control mechanism for intentional data based on provenance as well as a control mechanism for delegation, i.e., for deploying rules at remote peers

Zaychik Moffitt, Vera

INRIA a CCSD electronic archive server

HAL Id: hal-00850754https://hal.inria.fr/hal-00850754Submitted on 8 Aug 2013HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.Introducing Access Control in WebdamlogSerge Abiteboul, Émilien Antoine, Gerome Miklau, Julia Stoyanovich, VeraZaychik MoffittTo cite this version:Serge Abiteboul, Émilien Antoine, Gerome Miklau, Julia Stoyanovich, Vera Zaychik Moffitt. Introduc-ing Access Control in Webdamlog. DBPL - 14th International Symposium on Database ProgrammingLanguages - 2013, Aug 2013, Riva del Garda, Trento, Italy. ￿hal-00850754￿Introducing Access Control in Webdamlog ∗Serge AbiteboulÉmilien AntoineINRIA Saclay & ENS Cachanfirst.last@inria.frGerome MiklauINRIA Saclay & UMass Amherstmiklau@cs.umass.eduJulia StoyanovichVera Zaychik MoffittDrexel Universitystoyanovich@drexel.eduzaychik@drexel.eduAbstractWe survey recent work on the specification of an accesscontrol mechanism in a collaborative environment. The workis presented in the context of the WebdamLog language, anextension of datalog to a distributed context. We discuss afine-grained access control mechanism for intentional databased on provenance as well as a control mechanism fordelegation, i.e., for deploying rules at remote peers.1. IntroductionThe personal data and favorite applications of a Web userare typically distributed across many heterogeneous devicesand systems, e.g., residing on a smartphone, laptop, tablet,TV box, or managed by Facebook, Google, etc. Additionaldata and computational resources are also available to theuser from relatives, friends, colleagues, possibly via socialnetwork systems. Web users are thus increasingly at risk ofhaving private data leak and in general of losing control overtheir own information. In this paper, we consider a novelcollaborative access control mechanism that provides userswith the means to control access to their data by others andthe functioning of applications they run.Our focus is information management in environmentswhere both data and programs are distributed. In suchsettings, there are four essential requirements for accesscontrol:Data access Users would like to control who can read andmodify their information.Application control Users would like to control which ap-plications can run on their behalf, and what informationthese applications can access.Data dissemination Users would like to control howpieces of information are transferred from one partici-pant to another, and how they are combined, with theowner of each piece keeping some control over it.Declarativeness The specification of the exchange of data,applications, and of access control policies should bedeclarative. The goal is to enable anyone to specify accesscontrol.To illustrate each of these requirements, let us considerthe functionalities of a social network such as Facebook, inwhich users interact by exchanging data and applications.∗ This work has been partially funded by the European ResearchCouncil under the European Community’s Seventh FrameworkProgramme (FP7/2007-2013) / ERC grantWebdam, agreement226513. http://webdam.inria.fr/First, a user who wants to control who sees her information,can use a classic access control mechanism, such as the onecurrently employed by Facebook, based on groups of friends.Next, let us consider a user who installs an application.This typically involves opening much of her data to a serverthat is possibly managed by an unknown third party. ManyFacebook users see this as unreasonable, and would like tocontrol what the application can do on their behalf, andwhat information the application can access. Third, withrespect to data dissemination, users would like to specifywhat other users can do with their data, e.g., whether theirfriends are allowed to show their pictures to their respectivefriends. Finally, the users want to specify access control ontheir data without having to write programs. Thus, thissimple example already demonstrates the need for each oneof the four above requirements.From a formal point of view, we define an access con-trol mechanism for WebdamLog, a declarative datalog-stylelanguage that emphasizes cooperation between autonomouspeers [2]. We obtain a language that allows for declarativelyspecifying both data exchange and access control policiesgoverning this exchange. There are different aspects to ouraccess control:• For extensional data, the mechanism is standard, basedon access control lists at each peer, specifying who ownsand who can read/write data in each relation of thatpeer.• For intentional data, the mechanism is more sophisti-cated and fine-grained. It is based on provenance. In brief,only users with read access to all the tuples that partic-ipated in the derivation of a fact can read this fact.• The previous two mechanisms are used by default, andwe also support the means of overriding them.• Finally, we introduce a mechanism for controlling theuse of delegation in WebdamLog, which allows peers todelegate work to remote peers by installing rules, and isone of the main originalities of WebdamLog.Note that access control is implemented natively as partof the WebdamLog framework. The main idea is to useextensional relations to specify access to extensional data.Thus accessibility of extensional facts is itself recorded asextensional facts, which can then be used by a WebdamLogprogram to derive access to intentional data.Organization This short paper is organized as follows.The Webdamlog language is presented in Section 2. InSection 3, we present some aspects of access control. Weconclude in Section 4.2. WebdamlogIn [2], we introduced Webdamlog, a novel Datalog-style rule-based language. In Webdamlog, each piece of informationbelongs to a principal. We distinguish between two kinds ofprincipals: peer and virtual principal. A peer, e.g., AlicePhoneor Picasa, has storage and processing capabilities, and canreceive and handle queries and update requests. A virtualprincipal, e.g., Alice or RockClimbingClub, represents a useror a group of users, and relies on peers for storage and pro-cessing. We further distinguish between facts, representinglocal tuples and messages between peers, and rules, whichmay be evaluated locally or delegated to other peers.Webdamlog is primarily meant to be used in a distributedsetting. Perhaps the main novelty of the language is thenotion of delegation, which amounts to a peer installing arule on another peer. In its simplest form, delegation is aremote materialized view. In its general form, it allows peersto exchange knowledge beyond simple facts, providing themeans for a peer to delegate work to other peers. We willnot describe Webdamlog in detail here, but will illustrate itwith examples, referring the interested reader to [2].The following are examples of Webdamlog facts:agenda@AlicePhone(12/12/2012, 10 : 00, John, Orsay)photos@Picasa(fileName : picture34.jpg,date : 09/12/2012, byteStream : 010001)writeSecret@Picasa(login : Alice, password : HG − FT23)The first fact represents a tuple in relation agenda on peerAlicePhone with information about an upcoming meeting,and the second, a photo in Alice’s Picasa account (a tuplein relation photos on peer Picasa). The third fact representsAlice’s login credentials for her Picasa account (in relationwriteSecret on peer Picasa). Suppose that Alice wishes toretrieve, and store on her laptop, photos from Fontainbleauoutings that were taken by other members of her rockclimbing group. To this effect, Alice issues the following rule:outingPhotos@AliceLaptop($pic) :-rockClimbingGroup@Facebook($member),findPhoto@AliceLaptop($member, $photos, $peer),$photos@$peer($pic, $meta),contains@$peer($meta, Fontainbleau)This rule is a standard Webdamlog rule that illustratesvarious salient features of the language. First, the rule isdeclarative. Second, the assignment of values to peer names(e.g., $peer) and relation names (e.g., $photos) is determinedduring rule evaluation. Third, for $peer assigned to a systemother than AliceLaptop (e.g., Picasa or Flickr), the activationof this rule will result in activating rules (by delegation),or in some processing simulating them in other systems.The evaluation of rules such as this one is performed bythe Webdamlog system, which is responsible for handingcommunication and security protocols, and also includes adatalog evaluation engine, namely the Bud system [5].The semantics of a Webdamlog rule depends on thelocation of the relations occurring in this rule. Let p be aparticular peer. We say that a rule is local to p if the relationsoccurring in the body are all in p; intuitively, p can run sucha rule. The effect of a rule will also depend on whether therelation in the head of the rule is local (to p) or not andwhether it is extensional or intentional.Generally speaking, Webdamlog supports the followingkinds of rules.• A. Local rule with local intentional head. These rules, likeclassical datalog rules, define local intentional relations,i.e., logical views.• B. Local rule with local extensional head. These rulesderive new facts that are inserted into the local data-base. Note that, by default, as in Dedalus [3], facts arenot persistent. To have them persist, we use rules of theform m@p(U) :- m@p(U). Deletion can be captured bycontrolling the persistence of facts.• C. Local rule with non-local extensional head. Factsderived by such rules are sent to other peers and storedin an extensional relation at that peer, implementing aform of messaging.• D. Local rule with non-local intentional head. Such a ruledefines a new intentional relation at a remote peer basedon local relations of the defining peer.• E. Non-local. Rules of this kind allow a peer to installa rule at a remote peer, which is itself defined in termsof relations of other remote peers. This is the delegationmechanism that enables the sharing of application logicby peers, for instance, obtaining logic (rules) from othersites, and deploying logic (rules) to other sites.3. Access control in WebdamlogWe present three simple examples that highlight particularaspects of access control in WebdamlLog.Fine-grained access control on intentional data Sup-pose that an intentional relation allPhotos@Alice has beenspecified by Alice. Suppose that Alice gives the right tofriends, say Bob and Sue, to insert pictures into this relation.Alice’s friends can do this by defining the rules:[at Bob] allPhotos@Alice($f) :- bobPhotos@Bob($f)[at Sue] allPhotos@Alice($f) :- suePhotos@Sue($f)(Relation names bobPhotos and suePhotos are underlined toindicate that they are extensional.) allPhotos@Alice is inten-tional and is now defined as the union of bobPhotos@Boband suePhotos@Sue.The read privilege on allPhotos@Alice is a prerequisiteto having access to the contents of this relation, but accessis also controlled by the provenance of each fact, makingread access fine-grained. One can think of each intentionalfact as carrying its provenance, i.e., how it has been derived.In our simple example of Alice’s album, the provenance ofa photo coming from Bob will simply be the provenance to-ken associated with the corresponding fact at Bob. Then,to be able to read a fact in allPhotos@Alice that is com-ing from bobPhotos@Bob, Charlie will need read access onbobPhotos@Bob. To see a slightly more complicated exam-ple, suppose that a fact F may be obtained by taking thejoin of two base facts F1, F2; and that the same fact may beobtained alternatively by projection of a fact F3. To accessF a peer would need to have read access to its container(the relation that contains it) as well as to facts that sufficeto derive it, here F3 or the pair (F1, F2). In other words, apeer that has read access to an intentional fact must havesufficient rights to derive that fact.Overriding the default semantics For intentional data,we use by default an access control based on the full prove-nance of each fact. (If a fact is derived in several ways, eachderivation specifies a sufficient access right.) Access controlbased on full provenance may be more restrictive than isneeded in some applications, and we provide the means tooverride it. Consider the following rule that Alice uses topublish her own photos to her friends:[at Alice] allPhotos@$x($f) :-alicePhotos@Alice($f), [hide friends@Alice($x)]Ignore the hide annotation first. This rule is copyingthe photos of Alice’s friends into their respective allPhotosrelations. A friend, say Pete, will be allowed to see one ofAlice’s photos only if he is entitled to read the relationfriends@Alice. Now, it may be the case that Alice does notwant to share this relation with Pete, and so Pete will notsee her photos. The effect of the hide annotation is thatthe provenance of facts coming from friends@Alice is hidden.With this annotation, Pete will be able to see the photos.This feature is indispensable in preventing access controlfrom becoming too restrictive.Controlling delegation Recall that general delegation al-lows rules with non-local relations in the body. This leads tosignificant flexibility for application development and is themain distinguishing feature of the Webdamlog framework.It also creates challenges for access control.The following example illustrates the danger of a simplis-tic semantics for non-local rules. Consider the two rules:[at Bob] message@Sue(“I hate you”) :- date@Alice($d)aliceSecret@Bob($x) :-date@Alice($d), secret@Alice($x)If we ignore access rights, by delegation, this results inrunning the following two rules at Alice’s peer:[at Alice] message@Sue(“I hate you”) :- date@Alice($d)aliceSecret@Bob($x) :-date@Alice($d), secret@Alice($x)Assuming date@Alice($d) succeeds, then by the first ruleAlice sends some hate mail to Sue, and by the second itsends the contents of the relation secret@Alice to Bob, evenif Alice did not give read access on this relation to Bob.The main reason for this problem is that (by the standardsemantics of Webdamlog) we are running the delegationrules as if they were run by Alice. Under access control, weare going to run them in a sandbox with Bob’s privileges.So with the first rule, the hate message will be sent butmarked as coming from Bob. And with the second, the datawill be sent only if Bob has read access to secret@Alice. So,for a client c delegating a rule to a server, the semantics ofdelegation under access control policies guarantees that:• If the rule has side effects (e.g., it results in the insertionof tuples in the relation of another peer), the author ofthe update is c.• The access privileges with which the rule executes arethose of c.Note that, in practice, Alice sends Sue a message saying thatthe author of the message is Bob. So, Sue may question thisfact and asks Alice to prove that this is indeed the case. Butif this is indeed the case, Alice has the delegation from Bobto prove her good faith.Delegation is at the heart of distributed processing. Withdelegation, a peer p can ask another peer q to do someprocessing on its behalf. A natural question is whether thiswill yield exactly the same semantics (with possibly verydifferent performance) as if p were getting the data locallyand running a local computation. It turns out that thesemantics is different. This is because q will use data that(i) q has access to; and (ii) p has access to (because of thesandboxing). On the other hand, a local computation at pis limited by (ii) but not by (i).4. ConclusionThe WebdamLog language has been introduced in [2]. Thesystem has been implemented and different aspects havebeen demonstrated in conferences [1, 4]. The access controlmechanism is currently being implemented. The fine-grainedmechanism for intentional data raises various issues. Inparticular, the materialization of intentional relations maygenerate lots of data if performed naively. This is the topicof on-going research.References[1] S. Abiteboul, E. Antoine, G. Miklau, J. Stoyanovich, andJ. Testard. [Demo] rule-based application development usingWebdamLog. In SIGMOD, 2013.[2] S. Abiteboul, M. Bienvenu, A. Galland, and E. Antoine. Arule-based language for Web data management. In PODS,2011.[3] P. Alvaro, W. R. Marczak, N. Conway, J. M. Hellerstein,D. Maier, and R. C. Sears. Dedalus: Datalog in Time andSpace. Technical Report UCB/EECS-2009-173, EECS De-partment, University of California, Berkeley, December 2009.[4] E. Antoine, A. Galland, K. Lyngbaek, A. Marian, and N. Poly-zotis. [Demo] Social Networking on top of the WebdamEx-change System. In ICDE, 2011.[5] J. M. Hellerstein. The declarative imperative: experiences andconjectures in distributed logic. SIGMOD Record, 39(1):5–19,2010.

Introducing Access Control in Webdamlog

Abstract

Similar works

Full text

Available Versions

INRIA a CCSD electronic archive server

CiteSeerX