LPOP: Challenges and Advances in Logic and Practice of Programming
LLPOP: Challenges and Advances in Logic and Practice ofProgramming
David S. Warren Yanhong A. LiuComputer Science Department, Stony Brook University
Abstract
This article describes the work presented at the first Logic and Practice of Programming(LPOP) Workshop, which was held in Oxford, UK, on July 18, 2018, in conjunction withthe Federated Logic Conference (FLoC) 2018. Its focus is challenges and advances in logicand practice of programming. The workshop was organized around a challenge problem thatspecifies issues in role-based access control (RBAC), with many participants proposing combinedimperative and declarative solutions expressed in the languages of their choice.
The focus of the 2018 Logic and Practice of Programming workshop was on logic and declarativelanguages for the practice of programming. Of particular interest were languages (1) that have aclear semantic foundation, so that they can be used for concise modeling of complex applicationproblems, facilitating formal proofs and automated analysis, and (2) that are also implementable, sothat the implementations can run as specified, as part of real applications. Also of interest were (a)the design of declarative languages, libraries, and tools that facilitate the construction of complexsystems and applications, (b) approaches to integrate declarative and procedural programming, and(c) the use of declarative languages to facilitate other programming paradigms, e.g., distributedprogramming. The target audience for these languages was students who wish to model complexapplication problems, and practitioners who want to use them.The goal of the workshop was to bring together the best people and best languages, tools,and ideas to help improve logic languages for the practice of programming and to improve thepractice of programming with logic and declarative programming. We prepared to organize theworkshop around a number of ”challenge problems”, including in particular expressing a set ofsystem components and functionalities clearly and precisely using a chosen description language.To that end, we created an extensive challenge for this purpose in the general area of role-basedaccess control. We also organized invited talks and additional presentations by the proponents ofsome well-known description methods. We grouped presentations of description methods by thekind of problems that they address, and tried to allow ample time to understand the strengths ofthe various approaches and how they might be combined.Potential workshop participants were invited to submit position papers (1 or 2 pages in PDFformat), and to state whether they wished to present a talk at the workshop, explaining how theywould express the challenge problem. Because we intended to bring together researchers from manyparts of logic and declarative languages and practice of programming communities, it was essentialthat all talks be accessible to non-specialists. 1 a r X i v : . [ c s . P L ] A ug he program committee invited attendees based on their position paper submissions and at-tempted to accommodate presentation requests in ways that fit with the broader organizationalgoals outlined above. The schedule for the presentation of contributed position papers that describe solutions to thechallenge problem follows.
Session 1: Logic and Practice of ProgrammingSession Chair: Marc Denecker09:00 Marc Denecker. Opening and introduction.09:10 Invited Talk: Michael Leuschel. Practical uses of Logic, Formal Methods, B and ProB.09:50 Invited Talk: Nicola Leone, Bernardo Cuteri, Marco Manna, Kristian Reale and Francesco Ricca.On the Development of Industrial Applications with ASP.Session 2: Security Policies as Challenge ProblemsSession Chair: Annie Liu11:00 Annie Liu. Introduction: Role-Based Access Control as a Programming Challenge.11:10 Thom Fruehwirth (in spirit). Discussions on RBAC and"Security Policies in Constraint Handling Rules".11:20 David S. Warren. LPOP2018 XSB Position Paper.11:30 Roberta Costabile, Alessio Fiorentino, Nicola Leone, Marco Manna, Kristian Realeand Francesco Ricca. Role-Based Access Control via JASP.11:40 Marc Denecker. The RBAC challenge in the Knowledge Base Paradigm.11:50 Tuncay Tekle. Role-Based Access Control via LogicBlox.12:00 Joost Vennekens. Logic-based Methods for Software Engineers and Business People.12:10 Yanhong A. Liu and Scott Stoller. Easier Rules and Constraints for Programming.12:20 All Workshop Participants. Questions about RBAC challenge solutions.Session 3: Challenge Solutions and Constraint SolvingSession Chair: K. Tuncay Tekle14:00 Panel: Practice of Modeling and Programming.Panel Chair: Peter Van Roy. Panelists: All Morning Speakers.14:30 Invited Talk: John Hooker. A Modeling Language Based on Semantic Typing.15:10 Neng-Fa Zhou and Hkan Kjellerstrand.A Picat-based XCSP Solver - from Parsing, Modeling, to SAT Encoding.15:20 Paul Fodor. Role-Based Access Control as a LP/CP/Prolog Programming Challenge.Session 4: Logic and Constraints in ApplicationsSession Chair: David Warren16:00 Invited Talk: Rustan Leino. The Young Software Engineers Guide to UsingFormal Methods.16:40 Torsten Schaub. How to upgrade ASP for true dynamic modelling and solving?16:50 Peter Van Roy. A software system should be declarative except where it interactswith the real world.17:00 All Workshop Participants. Questions about logic and constraints in real-world applications.17:10 Panel: Future of Programming with Logic and Knowledge.Panel Chair: David Warren. Panelists: All Afternoon Speakers17:40 David Warren and Annie Liu. Future of LPOP.17:50 Tuncay Tekle and Marc Denecker. Closing. .2 Organization The organizers and others responsible for the workshop were:
Chairs
David Warren Stony Brook UniversityAnnie Liu Stony Brook University
Program Committee Chairs
Marc Denecker KU LeuvenTuncay Tekle Stony Brook University
Program Committee
Molham Aref Relational AIManuel Carro IMDEA SoftwareThomas Eiter Technical University of ViennaJacob Feldman OpenRulesThom Frhwirth University of UlmMichael Kifer Stony Brook UniversityMark Miller GoogleEnrico Pontelli New Mexico State UniversityFrancesco Ricca University of CalabriaPeter Van Roy Universit catholique de LouvainJoost Vennekens Katholieke Universiteit LeuvenJan Wielemaker Vrije Universiteit AmsterdamNeng-Fa Zhou City University of New York http://lpop.cs.stonybrook.edu/
It contains the full workshop program with links to the presentation slides.
Four invited speakers gave excellent talks:John Hooker Carnegie Mellon UniversityRustan Leino Amazon Web ServicesNicola Leone University of CalabriaMichael Leuschel University of Dusseldorf
Speaker: John Hooker, Carnegie Mellon UniversityAbstract:
A growing trend in modeling is the construction of high-level modeling languagesthat invoke a suite of solvers. This requires automatic reformulation of parts of the problemto suit different solvers, a process that typically introduces many auxiliary variables. We show3ow semantic typing can manage relationships between variables created by different parts of theproblem. These relationships must be revealed to the solvers if efficient solution is to be possible.The key is to view variables as defined by predicates, and declaration of variables as analogous toquerying a relational database that instantiates the predicates. The modeling language that resultsis self-documenting and self-checks for a number of modeling errors.(Joint work with Andr Cir and Tallys Yunes.)
Slides: https://drive.google.com/file/d/1emvbNY9bp3AWn6h4EHI7y3VphaZZ7gYL/
Speaker: Rustan Leino, Amazon Web ServicesAbstract:
If programming was ever a hermit-like activity, those days are in the past. Like otherinternet-aided social processes, software engineers connect and learn online. Open-source reposito-ries exemplify common coding patterns and best practices, videos and interactive tutorials teachfoundations and pass on insight, and online forums invite and answer technical questions. Theseknowledge-sharing facilities make it easier for engineers to pick up new techniques, coding practices,languages, and libraries. This is good news in a world where software quality is as important asever, where logic specification can be used to declare intent, and where formal verification toolshave become practically feasible.In this talk, I give one view of the future of software engineering, especially with an eye towardsoftware quality. I will survey some techniques, look at the history of tools, and inspire with someexamples of what can be daily routine in the lives of next-generation software engineers.
Slides: https://drive.google.com/file/d/0B9ffoWLQuWUXRTRtRElodFliMW5uaVhYMGQtb1FiLTJXLTJZ/
Speaker: Nicola Leone, University of CalabriaAsbtract:
Answer Set Programming (ASP) is a powerful rule-based language for knowledge rep-resentation and reasoning that has been developed in the field of logic programming and nonmono-tonic reasoning. After many years of basic research, the ASP technology has become mature for thedevelopment of significant real-world applications. In particular, the well-known ASP system DLVhas undergone an industrial exploitation by a spin-off company called DLVSYSTEM srl, whichhas led to its successful usage in a number of industry-level applications. The success of DLV forapplications development is due also to its endowment with powerful development tools, supportingresearchers and software developers that simplify the integration of ASP in real-world applicationswhich usually require to combine logic-based modules within a complete system featuring user in-terfaces, services etc. In this talk, we first recall the basics of the ASP language. Then, we overviewour advanced development tools, and we report on the recent implementation of some challengingindustry-level applications of our system.(Joint work with Bernardo Cuteri, Marco Manna, Francesco Ricca)
Slides: https://drive.google.com/file/d/1GGWtDzsIVnh43_kLpPjA8h7P1kDUTkYA/
A paper describing this work is included in Appendix A.4 .4 Practical Uses of Logic, Formal Methods, B and ProB
Speaker: Michael Leuschel, University of DusseldorfAbstract:
Slides: https://drive.google.com/file/d/1Q19wdAQJiXBTRGiiYM_YjkYqyvEaSvqU/
A Jupyter notebook can be found at: https://drive.google.com/file/d/11UNiLAIlHLHTAmMH__d2JEqrm8kAzc6Z/
The domain and the specific functions and components of the challenge problem were selectedto give participants the opportunity to demonstrate the best features of their (preferred) logiclanguage. Those features may be from a broad spectrum: elegance, naturalness, compactness,modularity of expression, broadness of the functionality of the logic tools (e.g., a strong pointwould be if tools are available to prove correctness of your solutions), reuse of the specification tosolve different parts of the problem, efficiency, etc.Participants were free to select only a subset of the functions and components, or to implementvariants of them, as long as their solutions showed the utility of their logic approach.The domain of the challenge was Role-Based Access Control (RBAC). This is a security policyframework for controlling user access to resources based on roles. The challenge included functionsand components for several well-known variants and extensions of RBAC, each involving its ownset of constraints.Participants were free, indeed encouraged, to present solutions for other components that showspecific strengths of their logic, e.g., such as the aforementioned proof of correctness of logic so-lutions. We were interested as well in new challenges for logic systems, tasks that cannot yet besolved by existing systems but that pose an interesting research goal.The RBAC programming challenge is included in Appendix B. The slides for the presentationare in the first half of those at: https://drive.google.com/file/d/1kzfE_CTYfAYgGSLg75ZJojhF1fEk4BSC/
Participants were encouraged to include programs, specifications, and other related materialsin appendices to their position papers. These papers appear as appendices.5
Solutions to the Challenge
We summarize each proposed solution to the RBAC challenge in the following sections.
Nicola Leone presents joint work with Roberta Costabile, Alessio Fiorentino, Marco Manna, Kris-tian Reale, and Francesco Ricca that attacks the RBAC challenge problem using Answer SetProgramming (ASP), as implemented in the JASP system. JASP is an extension of the Javaprogramming language with an ASP solver, allowing a programmer to use Java for procedural,state-changing operations and use ASP for declarative query solving. To solve the RBAC challengeproblem, Java is used to update an external relational database and to read the state of the database,generate the necessary facts and rules in the correct form required for the ASP solver, invoke theASP solver to compute query answers declaratively, and finally update the external database basedon the query results when necessary. This approach separates the procedural aspects of the problemfrom the query aspects by implementing the procedural aspects in the procedural language Javaand the query aspects in the declarative ASP framework.Leone’s presentation describes in detail the issues around implementing the RBAC function
GetRolesShortestPlan , which he says is ”the hardest function” to implement in this framework. Itis mentioned that other tasks of the challenge can be solved in a similar way but no specifics aregiven. The slides for the presentation of Leone, et al. can be found at: https://drive.google.com/file/d/1cBOHB4Vj3QS21iwp_-fLB36-KUv8ZEGF/
David S. Warren approaches the RBAC challenge problem using classical Prolog, in particular,the version implemented in the XSB system [2], taking advantage of particular features of thatimplementation. The traditional approach would be to use Prolog’s assert and retract operationsto update RBAC facts stored in Prolog’s global internal database. But this approach is non-declarative. So instead Warren uses a data structure to represent a database state that is explicitlypassed through all defined update operations and query operations required to solve the challengeproblem. This makes them all purely declarative. The procedural aspects are integrated into thedeclarative logical framework by making all update predicates depend on input and output databasearguments. This can be seen as a primitive implementation of a kernel portion of TransactionLogic [1]. Integrity constraint checking can be done before or after database update, with Prolog’sstandard backtracking naturally handling ”transaction rollback” if a check fails. Warren notesthat Prolog’s DCG notation can be used to avoid having to explicitly pass the database parameterthrough all update operations.The main challenge with this approach is that of efficiency, i.e., whether this Prolog datastructure can compete in efficiency with Prolog’s native assert and retract and whether tabling,which is fundamental to XSB’s evaluation strategy, can be made efficient when applied to predicatescontaining the database as argument(s). These problems are attacked by the use of a data structuredefined in a new XSB package that supports update and query operations on a set of Prolog rulesstored in a complex, trie-based Prolog term, but no detailed discussion of performance is provided.Warren’s RBAC implementation solved all the update and direct query and aggregation prob-lems proposed in the challenge; he did not attempt the more complex optimization problems.6arren’s paper and RBAC solutions are included in Appendix C. His presentation slides areavailable at: https://drive.google.com/file/d/1DhgLh4LkUCs3JcrieqcPTdb_hBL8yoO4/
Marc Denecker, in joint work with Jo Deviendt, describes an approach to solving the RBAC chal-lenge problem in the framework of IDP, an implementation of a knowledge base paradigm. IDPuses first-order logic combined with inductive definitions to specify declarative knowledge, and thenapplies a variety of inference mechanisms to this static data to solve various knowledge problems.The difficult aspect of the RBAC tasks for this framework is how to incorporate the database up-date operations within this purely logical paradigm. This presentation is a theoretical explorationof how this might be done in the IDB framework; no actual code for any RBAC task is provided.The approach taken here is to add an explicit temporal argument to each predicate that describesthe RBAC state. Thus the procedural aspects of the problem are handled by using a temporal logicand explicitly reasoning with time. Then the framework needs ”boiler-plate” frame axioms thatdescribe the important properties of time, and also axioms that describe the properties of time forpredicates that contain a temporal argument. Finally, one must explore how the axioms can beefficiently processed by the inference mechanisms of IDP to ensure that this approach will lead topractical solutions to the various tasks of the RBAC challenge.The paper is provided in Appendix E. The slides of Denecker’s presentation are available at: https://drive.google.com/open?id=1Q5JHPuAwWPhBIBdbO_JyUikIeDlMswfy/
Tuncay Tekle presented a solution to the RBAC challenge using LogicBlox, a commercial systemfor developing enterprise transactions and analytics applications. The solution was enabled byLogicBlox’s powerful query language, LogiQL, which extends Datalog with constraint checking,aggregates, and updates.Tekle summarizes LogicBlox as ”a state-based system with a persistent database that can bemanipulated, where one can add facts to the database, and rules and constraints to the state, andquery the database at any point in time”. LogicBlox also uses command line scripting to executeblocks of rules, facts, etc.For the RBAC challenge, specifications of sets and relations, and constraints over them are easilywritten in LogiQL. So are relational queries over them, including recursive queries, all expressedeasily using Datalog rules. Aggregations such as count are expressed use special, extended forms ofrules, less direct than can be expressed using SQL. Updates are directly expressed with notations+ and - in the conclusions of rules.For the two optimization problems in administrative RBAC, a restricted version of one of themcould be expressed in the LogicBlox framework with some rewrite. The other optimization problemand the two planning problems could not be solved using LogicBlox.Tekle’s paper is included in Appendix F. The slides are available at: https://drive.google.com/open?id=1sp5poNjknmNVbkNhHYhyvupPY9VTeGyn/ .5 Logic with Interface: IDP with Python API, or DMN Joost Vennekens illustrated solving the RBAC challenge using an approach he had recently pro-posed. In this approach, a relation is represented as a list of tuples, directly written as so in thePython programming language, and a relational query is expressed using a Python generator ex-pression, such as ”all” for universal quantification. This way, programmers need to know only theprogramming constructs in Python, not those in logic programming systems.These programming constructs are taken as an interface to a logic programming systems, wherethe data and queries could be interpreted with a more general meaning, e.g., as constraints relatingthe data, instead of queries of some derived data from given data. This general meaning allowssome desired derived data be given and some other data be inferred.Vennekens had developed such a Python API for the IDP system. He expresses in Python twoexample relations and an example query from core RBAC in the RBAC challenge, but not the restof the functions and components.Vennekens also uses the recent Decision Model and Notation (DMN) standard to support thegeneral argument that more familiar notations to domain experts can help increase the impact oflogic-based methods to business people.This paper is provided in Appendix G. The slides can be found at: https://drive.google.com/open?id=1WYQjkfS1blOU5zvM5ZAzDm12akSGAoBk/
Annie Liu presented in joined work with Scott Stoller a solution to the RBAC challenge in a high-level language that extends the Python programming language. This work starts with DistAlgo, anextension of Python for distributed programming especially with high-level set and logical queries,and proposes to add rules, constraint optimizations, and backtracking.With DistAlgo, their solution specifies the hierarchical component structure of the challengeRBAC explicitly, as required in the challenge and as in the ANSI standard. This includes coreRBAC, hierarchical RBAC, core RBAC with constraints, hierarchical RBAC with constraints,and Administrative RBAC, as in the main challenge, as well as distributed RBAC as an optionalcomponent in the challenge.Each component includes the definitions of sets and relations, in addition to those inherited fromthe parent components if any, as well as all query and update operations. For computing transitiveclosures in hierarchical RBAC, they gave an implementation that uses high-level set queries andan alternative implementation that uses Datalog rules.All components and operations are fully executable in DistAlgo except for administrative RBAC,which needs the extensions for constraint optimization and backtracking, and the alternative im-plementation of transitive closure using rules.This paper including the solution program is provided in Appendix H. The slides for the pre-sentation are in the second half of those at: https://drive.google.com/file/d/1kzfE_CTYfAYgGSLg75ZJojhF1fEk4BSC/
Paul Fodor presented different logic programming solutions to the problem of minimum role as-signments with hierarchy in Administrative RBAC. This is formulated as a constraint optimizationproblem, and as such does not address the issues of state update and imperative programming.8odor used this problem as the first problem in the Logic Programming and Constraint Pro-gramming Contest at ICLP 2018 ( https://sites.google.com/site/prologcontest2018/ ). Hepresented the best four solutions, two in ASP, one in Prolog, and one in Picat. The two ASP so-lutions both used the https://drive.google.com/file/d/1aszplEMEUdUyaUqNU8_GhFtzbLN42dmf/
Thom Fruhwirth provided a position paper on the use of CHR for the representation of securitypolicies, but he did not provide a solution to the RBAC challenge. He was unable to attend theworkshop to give a presentation. His paper can be found in Appendix I.
Some authors and presenters did not address the RBAC challenge but discussed methods, tools,and ideas for integrating different programming paradigms. We summary each of these below.
In his presentation ”How to upgrade ASP for true dynamic modelling and solving” Torsten Schaubdiscusses the issues involved in extending ASP concepts and implementations in ways that supportthe solving of dynamic problems, i.e., problems that involve data that change over time. Hediscusses three important aspects of extending ASP in this direction: modeling, encoding andsolving, and bench-marking. Modeling issues involve what formal extension to the logic of ASP isappropriate for specifying dynamic systems. Schaub proposes Temporal Equilibrium Logic, whichcombines the ideas of the logic of Here-and-There with Linear Temporal Logic. Encoding involveshow to represent a problem in the modeling language in such a way that it can be efficientlysolved by ASP solvers and their extensions. And finally Schaub emphasizes the importance ofgood, scalable, realistic benchmarks that allow various systems to be effectively compared. Heproposes that benchmarks be developed to address the real-world problem of controlling warehouseoperations that use robot vehicles to retrieve items from mobile shelves. He argues that this providesan excellent domain for exploring many aspects of using an ASP framework for dynamic systems.This paper is available in Appendix J. The slides for this talk can be found at: https://drive.google.com/file/d/1GUQC4qXYkt9lK3te0Uc6ZrEFgYNDLQuX/view
Neng-Fa Zhou presented joint work with Hakan Kjellerstrand in a presentation titled ”A Picat-based XCSP Solver - from Parsing, Modeling, to SAT Encoding.” The presentation provides anoverview of a Picat-based XCSP3 solver, named PicatSAT, which demonstrates the strengths ofPicat, a logic-based language, in parsing, modeling, and encoding constraints into SAT. XCSP3 is9n XML-based language for specifying constraint satisfaction problems, and PicatSAT uses Picatto process these specifications. The presentation included a brief description of parsing the XCSP3language, the advantages of using specialized Picat constructs to compactly implement a variety ofconstraints, and issues involved in encoding SAT problems in Picat.This paper is provided as Appendix K. The slides are available at: https://drive.google.com/file/d/1-F0RwPQVISeqzR1yr1_wkdvGcsT_i4Hq/
Peter Van Roy proposes a principle for combining declarative programming and imperative pro-gramming when building software systems. While declarative programming supports ease of rea-soning for analysis, verification, optimization, and maintenance, it cannot express interaction withthe real world, because it does not support common real-world concepts such as physical timeand named state, which are supported by imperative programming. Therefore, the principle is: asoftware system should be declarative except where it interacts with the real world.Examples such as the client-server model from distributed computing are used as motivation,and a formal argument is outlined using lambda-calculus and an extension.Van Roy’s paper is provided as Appendix L. The slides for the talk can be viewed at: https://drive.google.com/file/d/1qVrRwsO3b9LJv8OdhCF_Ali98Gpz443t/
The workshop was deemed a success, with the panel discussions and audience participation thatfollowed invited talks and paper presentations being particular noteworthy. The intention of theorganizers is to hold LPOP every two years. LPOP 2020 was initially intended to be held inconjunction with LICS 2020 in Beijing, but due to travel complexities will instead be held inconjunction with SPLASH 2020.
References [1] Anthony J. Bonner and Michael Kifer. Transaction logic programming. In
ICLP , 1993.[2] David S. Warren, Terrance Swift, and Konstantinos F. Sagonas. The XSB programmer’s manual,Version 2.7.1. Technical report, Department of Computer Science, State University of New Yorkat Stony Brook, Stony Brook, New York, 11794-4400, Mar 2007. The XSB System is availablefrom xsb.sourceforge.net, and the system and manual is continually updated.10 n the Development of Industrial Applicationswith ASP
Nicola Leone , , Bernardo Cuteri ,Marco Manna , Kristian Reale , and Francesco Ricca University of Calabria, Italy DLVSystem s.r.l, Italy [email protected]
Abstract.
Answer Set Programming (ASP) is a powerful rule-basedlanguage for knowledge representation and reasoning that has been de-veloped in the field of logic programming and nonmonotonic reasoning.After many years of basic research, the ASP technology has become ma-ture for the development of significant real-world applications. In par-ticular, the well-known ASP system DLV has undergone an industrialexploitation by a spin-off company called DLVSYSTEM srl, which hasled to its successful usage in a number of industry-level applications.The success of DLV for applications development is due also to its en-dowment with powerful development tools, supporting researchers andsoftware developers that simplify the integration of ASP in real-world ap-plications which usually require to combine logic-based modules withina complete system featuring user interfaces, services etc. In this talk, wefirst recall the basics of the ASP language. Then, we overview our ad-vanced development tools, and we report on the recent implementationof some challenging industry-level applications of our system.
Answer Set Programming (ASP) [1] is a powerful rule-based language for knowl-edge representation and reasoning that has been developed in the field of logicprogramming and nonmonotonic reasoning. ASP features disjunction in ruleheads, non monotonic negation in rule bodies, aggregate atoms for concise mod-eling of complex combinatorial problems, and weak constraints for the declara-tive encoding of optimization problems.Computational problems, even of high complexity [2], can be solved in ASPby specifying a logic program —i.e., of a set of logic rules— such that its answersets correspond to solutions, and then, using an answer set solver to find suchsolutions [1].After more than twenty years from the introduction of ASP, the theoreti-cal properties of the language are well understood and the solving technologyhas become mature [6] for practical applications. The high knowledge-modelingpower of ASP made it suitable for solving a variety of complex problems arisingin scientific applications [6] from several areas ranging from
Artificial Intelligence to Knowledge Management and
Databases [3].
Appendix A F. Author et al.
Recently, the well-known ASP system DLV [8] has undergone an industrialexploitation by a spin-off company called DLVSYSTEM srl, favoring the inter-est of some industries in ASP and DLV, which has led to its successful usagein a number of industry-level applications [7]. A key advantage of DLV for ap-plications development is its endowment with powerful development tools [5, 4],supporting the activities of researchers and implementors.In the invited talk, after a brief introduction to the ASP standard language,we illustrate its usage for advanced Knowledge Representation and Reasoningby presenting a number of industry-level real-world applications of ASP, that wehave implemented by using the DLV system and its accompanying tools, namely: – A platform employed by the call-centers of Italia Telecom, which automati-cally classifies the incoming calls for optimal routing. The platform works inreal-time and deals with a very large number of parallel calls. – A novel architecture for closed domain question answering in natural lan-guage in the cultural heritage context. In particular, we implemented a tem-plate matching based on ASP for question classification and query extrac-tion. – A tool for travel agents for the intelligent allotment of touristic packages [ ? ].Basically, the system selects from service-suppliers blocks of touristic pack-ages to be pre-booked for the next season in such a way that the expectedearnings are maximized, and a number of preference criteria are satisfied. – A tool for the automatic generation of the teams of employees [10] thathas been employed in the sea port of Gioia Tauro for intelligent resourceallocation.Moreover, we overview two advanced development tools for ASP, namely AS-PIDE [5] and JDLV [4], that have been developed to address some of the difficul-ties encountered by applying DLV in the above mentioned applications. ASPIDEis an extensible integrated development environment for ASP, which integratespowerful editing tools with a collection of development tools for program test-ing and rewriting, database access, solver execution configuration and output-handling. JDLV is a plug-in for Eclipse, supporting a hybrid language that trans-parently enables a bilateral interaction between ASP and Java. The developmenttools support researchers and software developers and simplify the integrationof ASP in mature widely-adopted development platforms based on imperativeand object-oriented programming languages.
References
1. Brewka, G., Eiter, T., Truszczynski, M.: Answer set programming at a glance.Commun. ACM (12), 92–103 (2011)2. Eiter, T., Gottlob, G., Mannila, H.: Disjunctive Datalog. ACM Trans. DatabaseSyst. (3), 364–418 (Sep 1997)3. Erdem, E., Gelfond, M., Leone, N.: Applications of answer set programming. AIMagazine (3), 53–68 (2016) n the Development of Industrial Applications with ASP 34. Febbraro, O., iGiovanni Grasso, Leone, N., Ricca, F.: JASP: a framework for in-tegrating Answer Set Programming with Java. In: Proc. of KR2012. AAAI Press(2012)5. Febbraro, O., Reale, K., Ricca, F.: ASPIDE: Integrated Development Environmentfor Answer Set Programming. In: Delgrande, J., Faber, W. (eds.) Logic Program-ming and Nonmonotonic Reasoning — 11th International Conference, LPNMR’11,Vancouver, Canada, May 2011, Proceedings. vol. 6645, pp. 317–330. Springer Ver-lag (May 2011)6. Gebser, M., Maratea, M., Ricca, F.: The sixth answer set programming competi-tion. J. Artif. Intell. Res. , 41–95 (2017)7. Grasso, G., Leone, N., Manna, M., Ricca, F.: Logic Programming, Knowledge Rep-resentation, and Nonmonotonic Reasoning: Essays in Honor of Michael Gelfond,vol. 6565. Springer Verlag (2011)8. Leone, N., Pfeifer, G., Faber, W., Eiter, T., Gottlob, G., Perri, S., Scarcello, F.:The DLV System for Knowledge Representation and Reasoning (3), 499–562 (Jul2006)9. Ricca, F., Dimasi, A., Grasso, G., Ielpa, S.M., Iiritano, S., Manna, M., Leone, N.:A Logic-Based System for e-Tourism. Fundam. Inform. ((1–2)), 35–55 (2010)10. Ricca, F., Grasso, G., Alviano, M., Manna, M., Lio, V., Iiritano, S., Leone, N.:Team-building with answer set programming in the gioia-tauro seaport. Theoryand Practice of Logic Programming. Cambridge University Press (3), 361–381(2012). https://doi.org/doi:10.1017/S147106841100007X ole-Based Access Control as a Programming Challenge Yanhong A. Liu ∗ This programming challenge description focuses on a small but rich set of problems froman important practical application domain, Role-Based Access Control (RBAC). The goalis to allow the use of a wide variety of essential programming constructs to (cid:28)rst specify theproblems clearly and then solve the problems e(cid:30)ciently, as much as possible. • Role-Based Access Control (RBAC) is a security policy framework for controlling useraccess to resources based on roles [3, 9]. It is extremely important for reducing thecost of policy administration, especially in large organizations. • The problems include updates, for actions and transactions, and queries, for checking,analysis, optimization, and planning, in the presence of constraints, naturally organizedinto a set of components for ease of use by the applications.The RBAC programming challenge is described in the next two pages.Among the (cid:28)ve RBAC components described, functionalities of the (cid:28)rst four are cre-ated based on the ANSI standard for RBAC [4, 1] but reduced to contain only the mostessential concepts and improved to avoid discovered anomalies [8, 6]. Functionalities in thelast component are created to correspond to role mining [2] and generalize from user-rolereachability [10]. • As a programming challenge, any subset of self-contained components and functional-ities can be used, and the rest can be made optional. • Additional RBAC components and functionalities can also be added, for example, forsessions and for dynamic separation of duty (DSD) constraints in the ANSI standard [4,1], for role mining with probabilistic models [5], and for trust management [7] (alsocalled distributed RBAC) in decentralized systems. • Furthermore, one may add a veri(cid:28)cation component for proving or checking the con-straints, a Graphical User Interface (GUI) component, a particular RBAC policy foran RBAC system, and a test component for correctness and performance testing.This programming challenge is created for the Workshop on Logic and Practice of Pro-gramming (LPOP) at the Federated Logic Conference (FLOC), Oxford, UK, July 18, 2018.The emphasis is on clearly expressing the problem logic (cid:28)rst before improving the programe(cid:30)ciency. Any languages and systems can be used. ∗ Author’s contact: Computer Science Department, Stony Brook University, Stony Brook, New York.Email: [email protected] Appendix B BAC programming challenge
We consider Role-Based Access Control (RBAC) with 5 components:Core RBACHierarchical RBACCore RBAC with Static Separation of Duty (SSD) constraint (a.k.a. Constrained RBAC)Hierarchical RBAC with SSD constraintAdministrative RBACCore RBAC keeps several sets including the following:
USERS : set of users
ROLES : set of roles
PERMS : set of permissions UR : set of user-role pairs PR : set of permission-role pairswith constraints: UR is subset of USERS * ROLESPR is subset of
PERMS * ROLES update functions for each set, subject to the constraints above:
AddUser , DeleteUser , AddRole , DeleteRole , AddPerm , DeletePermAddUR , DeleteUR , AddPR , DeletePR , whereeach
Add has pre-conditions: the element is not in and no constraints will be violated, andeach
Delete has the pre-condition that the element is in, and maintains the constraints byupdates if neededand query functions including the following:
AssignedRoles(user) : the set of roles assigned to user in URUserPermissions(user) : the set of permissions assigned to the roles assigned to userCheckAccess(user, perm) : whether some role is assigned to user and is granted perm
Hierarchical RBAC extends CoreRBAC and keeps also a role hierarchy: RH : set of pairs of roles, called ascendant and descendant roles,where an ascendant role inherits permissions from a descendant rolewith constraints: RH is subset of ROLES * ROLES , and RH is acyclicupdate functions for RH , subject to the constraints above: AddInheritance(asc, desc) , DeleteInheritance(asc, desc) , whereeach update has the same kinds of pre-conditions as updates in CoreRBACand query functions including the following:
Trans() : the transitive closure of role hierarchy unioned with the re(cid:29)exive role pairs
AuthorizedRoles(user) : the set of roles of user and their transitive descendant roles2 ore RBAC with SSD extends CoreRBAC and keeps also a set of SSD items, whereeach item has: a name, a set of roles, and a cardinalitywith constraints:all roles in all SSD items are in ROLES for each SSD item, its cardinality is greater than 0 and less than the number of its rolesfor each user, for each SSD item, the number of assigned roles (
AssignedRoles ) of the userthat are in the item’s set of roles is at most the item’s cardinalityupdate functions, subject to the constraints above:
CreateSsdSet(name, roles, c) : add SSD item having name , roles , and cardinality cDeleteSsdSet(name) : delete SSD item having nameAddSsdRoleMember(name, role) : add role to roles of SSD item having nameDeleteSsdRoleMember(name, role) : delete role from roles of SSD item having nameSetSsdSetCardinality(name, c) : set c to be cardinality of SSD item having name , whereeach update has the same kinds of pre-conditions as updates in CoreRBAC, except thatall updates have also pre-conditions that no constraints will be violatedand query functions including the following: SsdRoleSets() : the set of names of SSD items
SsdRoleSetRoles(name) : the set of roles in SSD item having nameSsdRoleSetCardinality(name) : the cardinality of SSD item having name
Hierarchical RBAC with SSD extends both Hierarchical RBAC and Core RBAC withSSD and combines all from both except that the SSD constraint uses
AuthorizedRoles inplace of
AssignedRoles
Administrative RBAC could extend each of the previous 4 components; we consider ex-tending the last, HierarchicalRBACwithSSD, with optimization and planning functions:
MinRoleAssignments :(cid:28)nd
ROLES’ , UR’ , and
PR’ with the smallest total size of
UR’ and
PR’ such that each user has the same permission through
AuthorizedRoles as before
MinRoleAssignmentsWithHierarchy :(cid:28)nd
ROLES’ , UR’ , PR’ , and
RH’ with the smallest total size of
UR’ , PR’ , and
RH’ such that each user has the same permissions through
AuthorizedRoles as before
GetRolesPlan(user, roles, acts) :(cid:28)nd a sequence of actions, i.e., updates, in acts that allows user to get rolesGetRolesShortestPlan(user, roles, acts) :(cid:28)nd a shortest sequence of actions, i.e., updates, in acts that allows user to get roles and an operation:
GetRoles(user, roles, acts) :perform a sequence of actions in acts that allows user to get roles if possibleAny subset of updates can be used as acts . All constraints must hold after each update.3 cknowledgment Many thanks to Scott Stoller for helpful references and discussions and to Marc Deneckerand Scott Stoller for helpful comments and suggestions.
References [1] ANSI INCITS. Role-Based Access Control. ANSI INCITS 359-2004, American NationalStandards Institute, International Committee for Information Technology Standards,Feb. 2004.[2] A. Ene, W. G. Horne, N. Milosavljevic, P. Rao, R. Schreiber, and R. E. Tarjan. Fastexact and heuristic methods for role minimization problems. In Proceedings of the 13thACM Symposium on Access Control Models and Technologies, pages 1(cid:21)10, 2008.[3] D. Ferraiolo and R. Kuhn. Role-based access control. In Proceedings of the 15th NIST-NSA National Computer Security Conference, pages 554(cid:21)563, Blatimore, Maryland,1992.[4] D. F. Ferraiolo, R. Sandhu, S. Gavrila, D. R. Kuhn, and R. Chandramouli. ProposedNIST standard for role-based access control. ACM Transactions on Information andSystems Security, 4(3):224(cid:21)274, 2001.[5] M. Frank, J. M. Buhmann, and D. A. Basin. Role mining with probabilistic models.ACM Transactions on Information and System Security, 15(4):1(cid:21)28, 2013.[6] N. Li, J.-W. Byun, and E. Bertino. A critique of the ANSI standard on role-based accesscontrol. IEEE Security and Privacy, 5(6):41(cid:21)49, 2007.[7] N. Li, J. C. Mitchell, and W. H. Winsborough. Design of a role-based trust-managementframework. In Proceedings of the 2002 IEEE Symposium on Security and Privacy, pages114(cid:21)130, 2002.[8] Y. A. Liu and S. D. Stoller. Role-based access control: A corrected and simpli(cid:28)edspeci(cid:28)cation. In Department of Defense Sponsored Information Security Research: NewMethods for Protecting Against Cyber Threats, pages 425(cid:21)439. Wiley, 2007.[9] R. Sandhu, E. Coyne, H. Feinstein, and C. Youman. Role-based access control models.IEEE Computer, 29(2):38(cid:21)47, 1996.[10] S. D. Stoller, P. Yang, C. Ramakrishnan, and M. I. Gofman. E(cid:30)cient policy analysis foradministrative role based access control. In Proceedings of the 14th ACM Conferenceon Computer and Communications Security, 2007.4 POP2018 XSB Position Paper
David S. WarrenDepartment of Computer ScienceStony Brook University, New York, USAMay 30, 2018
In this position paper we first describe a classic logic programming approach tothe solution of (a portion) of the challenge problem involving RBAC. We use theXSB Tabled Prolog Language and system [3], with ideas from Transaction Logic[1]. Then we discuss efficiency and scalability issues for this implementation.Finally we discuss issues that involve what would be required to use such animplementation in a real-world application requiring RBAC functionality.
We describe our solution to the challenge problem. We use a module, prolog db ,that was recently added to the XSB system that allows a Prolog database (i.e., aset of clauses) to be represented as a ground term, which we call a PDB. A num-ber of operations are provided to access and update PDB’s, the salient ones herebeing a) assert in db(+Clause,+PDB0,-PDB) , which adds a clause to a PDB togenerate a new PDB, b) retract in db(+Clause,+PDB0,-PDB) , which deletesa clause from a PDB to generate a new PDB, and c) call in db(?Goal,+PDB) ,which calls a goal in a given PDB, returning instances that are true in the givenPDB. For this RBAC application the clauses in a PDB will always be groundfacts. We use the Prolog Definite Clause Grammar (DCG) notation for writingthese programs, since it supports a convenient notation for writing rules thatdefine state transformations. The (implicit) state is always a PDB.The description of the RBAC challenge problem is given at https://drive.google.com/file/d/1q9W15kI624TI6pEbh2IMPDw6X5_5MiW7/view .The XSB program for the RBAC challenge problem (minus the two
MinRoleAssignment functions in the Administrative component) is provided in the Appendix.This is a relatively straightforward specification (and implementation) ofthe problem in classical logic programming. Since the RBAC database is repre-sented explicitly as a term in Prolog, general Prolog backtracking restores earlierdatabase states. So this makes post conditions, such as in create ssdSet , triv-ial to implement: do the operation, and then check the post condition; if it fails,the system automatically backtracks to restore the initial database state.Note also that the tabling is correct even as the PDBs change, since theappropriate PDBs, which are implicit in the DCG notation, are arguments tothe tabled predicates. One might want to abolish the tables periodically if spacebecomes an problem. 1
Appendix C .1 Performance Issues This implementation should be quite efficient as an XSB program. A PDB rep-resents a set of clauses. The prolog db module uses a trie data structure tostore a PDB, with a variant of a radix tree at each branch point in the trie.This makes the representation canonical, in that a given set of clauses is rep-resented by the same term, regardless of the sequence of asserts and retracts( in db) that generates that set. So all updates and accesses are done in logtime. Also, the terms representing PDBs are ground and so can use “internedterms”, also sometimes known as hash-consing, which are implemented in XSB[2]. Thus the terms are copied to a global store and uniquely stored; i.e. allcommon subterms are shared. Then the Prolog code passes around what areessentially pointers to tries in the global store. With this representation tablinginvolves only the constant-time copying of a “pointer” into and out of a table.Also equality comparison of two PDBs is simply a comparison of their point-ers. The
GetRoles(Shortest)Plan functions do an exhaustive search for plans,which in some cases could be expensive, but the tabling does provide help. Thetwo
MinRoleAssignments functions are not implemented because they seem torequire constraint solving, which is not XSB’s strength. An exhaustive searchcould be implemented directly in XSB but would be uninteresting.
So this seems to us to be a reasonably elegant solution to the formal RBACproblem as specified in (all but two functions of) the challenge. However, thereis the question of how this code might really be used in a much larger systemin which access control is only a small component. As described in the pre-vious subsection, we don’t think that the performance and scalability of theexecution of the RBAC operations would present a problem. The more difficultissues, we believe, involve data persistence and concurrent usage. There arevarious potential solutions, but no single obvious one (at least to us.) And thepotential solution seem to require procedural, more than logical, thinking andprogramming.
References [1] A. J. Bonner and M. Kifer. An overview of transaction logic.
TheoreticalComput. Sci. , 133:205–265, October 1994.[2] D. S. Warren. Interning ground terms in XSB. In
Proceedings of CICLOPS2013 , August 2013. In conjunction with ICLP’2013.[3] D. S. Warren, T. Swift, and K. F. Sagonas. The XSB programmer’s manual,Version 2.7.1. Technical report, Department of Computer Science, StateUniversity of New York at Stony Brook, Stony Brook, New York, 11794-4400, Mar 2007. The XSB System is available from xsb.sourceforge.net, andthe system and manual is continually updated.2 RBAC Implementation in XSB :- import assert_in_db/3, retractall_in_db/3, call_in_db/2, size_db/2, new_dbi/1from prolog_db.%% rename update operations for clarity (and brevity)add(Fact,DB0,DB) :- assert_in_db(Fact,DB0,DB).del(Fact,DB0,DB) :- retractall_in_db(Fact,DB0,DB).%% CORE RBAC%% Make relation lookups into identity transactions (convenience)%% i.e., they return the exact database they receive.users(User,D,D) :- call_in_db(users(User),D).roles(Role,D,D) :- call_in_db(roles(Role),D).perms(Perm,D,D) :- call_in_db(perms(Perm),D).ur(User,Role,D,D) :- call_in_db(ur(User,Role),D).pr(Perm,Role,D,D) :- call_in_db(pr(Perm,Role),D).%% update functions%% to add and delete users...addUser(User) --> \+ users(User), add(users(User)).deleteUser(User) --> users(User), \+ ur(User,_), del(users(User)).%% to add and delete roles...addRole(Role) --> \+ roles(Role), add(roles(Role)).deleteRole(Role) --> roles(Role), \+ ur(_,Role), \+ pr(_,Role), del(roles(Role)).%% to add and delete permissions...addPerm(Perm) --> \+ perms(Perm), add(perms(Perm)).deletePerm(Perm) --> perms(Perm), \+ pr(Perm,_), del(perms(Perm)).%% to add and delete users in rolesaddUR(User,Role) --> users(User), roles(Role), \+ ur(User,Role), add(ur(User,Role)).deleteUR(User,Role) --> ur(User,Role), del(ur(User,Role)).%% to add and delete permissions that roles have.addPR(Perm,Role) --> perms(Perm), roles(Role), \+ pr(Perm,Role), add(pr(Perm,Role)).deletePR(Perm,Role) --> pr(Perm,Role), del(pr(Perm,Role)).%% simple rename as requiredassignedRoles(User,Role) --> ur(User,Role).%% define user permissions by joining user-role and role-permissionuserPermissions(User,Perm) --> ur(User,Role), pr(Perm,Role).%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% HIERARCHICAL RBAC (additions)%% immediate subclass relation to identity transaction%% (would be more efficient in other order..)rh(RoleAsc,RoleDsc,D,D) :- call_in_db(rh(RoleAsc,RoleDsc),D).%% update functions%% add an inheritance fact if no loop is generatedaddInheritance(RoleAsc,RoleDsc) -->roles(RoleAsc),roles(RoleDsc),add(rh(RoleAsc,RoleDsc)), + trans(RoleAsc,RoleDsc).%% define transitive closure for inheritance, and loop checking%% note that the db is a (hidden) parameter, so this is correct over updates:- table trans/4.trans(Dsc,Dsc) --> [].trans(Dsc,Asc) --> trans(Dsc,Par),rh(Asc,Par).%% remove an inheritance fact.deleteInheritance(RoleAsc,RoleDsc) -->rh(RoleAsc,RoleDsc),del(rh(RoleAsc,RoleDsc)).%% add rule to include inheritance when determining authorized rolesauthorizedRoles(User,Role) -->trans(Role,ARole),assignedRoles(User,ARole).%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% SSD%% again make lookup operations into identity transactions, for convenience.ssdCount(Name,Cnt,D,D) :- call_in_db(ssdCount(Name,Cnt),D).ssdRole(Name,Role,D,D) :- call_in_db(ssdRole(Name,Role),D).%% add ssdRole and check consistencyaddSsdRoleMember(Name,Role) -->roles(Role),add(ssdRole(Name,Role)),ssdConsistent(Name).%% delete ssdRoledeleteSsdRoleMember(Name,Role) -->ssdRole(Name,Role),del(ssdRole(Name,Role)).%% set SSD cardinalitysetSsdSetCardinality(Name,Cnt) -->(ssdCount(Name,OCnt) % if already has a cardinality->({OCnt \== Cnt} % if cardinality is changed-> del(ssdCount(Name,OCnt)),add(ssdCount(Name,Cnt)),ssdConsistent(Name) % check consistency after update; [] % no change, no need to check consistency); add(ssdCount(Name,Cnt)), % create initial cardinalityssdConsistent(Name) % check consistency).%% ssd set opsdeleteSsdSet(Name) -->ssdCount(Name,_),del(ssdCount(Name,_)),del(ssdRole(Name,_)).create_ssdSet(Name,RoleList,Cnt) -->\+ ssdCount(Name,_), dd(ssdCount(Name,Cnt)),addSsdRoleMembers(Name,RoleList),ssdConsistent(Name).%% add role membersaddSsdRoleMembers(_,[]).addSsdRoleMembers(Name,[Role|Roles]) :-roles(Role),add(ssdRole(Name,Role)),addSsdRoleMembers(Name,Roles).%% define consistency.ssdConsistent(Name) --> ssdConsistentAssigned(Name).%% or if include authorized, would use the following clause:%% ssdConsistent(Name) --> ssdConsistentAuthorized(Name).%% consistent if not inconsistentssdConsistentAssigned(Name) -->\+ ssdInconsistentAssigned(Name).%% inconsistency is more easily definedssdInconsistentAssigned(Name) -->ssdCount(Name,Cnt),ssdAssignedRoleCnt(Name,_User,UCnt),{UCnt > Cnt}.%% aggregation predicate for counting rolessum(A,B,C) :- C is A + B.%% aggregate using sum (admittedly, a bit awkward...):- table ssdAssignedRoleCnt(_,_,fold(sum/3,0),_,_).ssdAssignedRoleCnt(Name,User,1) -->assignedRoles(User,Role),ssdRole(Name,Role).%% same as above but using authorized as opposed to assigned.ssdConsistentAuthorized(Name) -->\+ ssdInconsistentAuthorized(Name).ssdInconsistentAuthorized(Name) -->ssdCount(Name,Cnt),ssdAuthorizedRoleCnt(Name,_User,UCnt),{UCnt > Cnt}.:- table ssdAuthorizedRoleCnt(_,_,fold(sum/3,0),_,_).ssdAuthorizedRoleCnt(Name,User,1) -->authorizedRoles(User,Role),ssdRole(Name,Role). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Administrative RBAC (Planning functions)%% Exhaustive search for a plan:- table getRolesPlan/6.getRolesPlan(User,Roles,Acts,PlanSet) -->(hasAllRoles(User,Roles) % at the goal, so->{new_dbi(PlanSet)} % no actions needed; {member(Act,Acts)}, % for each actioncall(Act), % perform itgetRolesPlan(User,Roles,Acts,PlanSet0), % search from new DB{assert_in_db(Act,PlanSet0,PlanSet)} % succeeded, add this act).%% check goal statehasAllRoles(_,[]) --> [].hasAllRoles(User,[Role|Roles]) -->authorizedRoles(User,Role),hasAllRoles(User,Roles).%% Search for shortest plan:%% Same as above, but only keep plans with fewest actions:- table getRolesShortestPlan(_,_,_,lattice(smaller_plan/3),_,_).getRolesShortestPlan(User,Roles,Acts,PlanSet) -->(hasAllRoles(User,Roles)->{new_dbi(PlanSet)}; {member(Act,Acts)},call(Act),getRolesShortestPlan(User,Roles,Acts,PlanSet0),{assert_in_db(Act,PlanSet0,PlanSet)}).%% Plan2 is the smaller of Plan0 and Plan1smaller_plan(Plan0,Plan1,Plan2) :-size_db(Plan0,N0),size_db(Plan1,N1),(N0 =< N1->Plan2 = Plan0; Plan2 = Plan1). ole-Based Access Control via JASP Roberta Costabile , Alessio Fiorentino , Nicola Leone , ,Marco Manna , Kristian Reale , , and Francesco Ricca University of Calabria, Italy –
Abstract.
In this paper, we answer the Role-Based Access Control(RBAC) challenge by showcasing the solution of RBAC components byusing JASP, a flexible framework integrating ASP with Java. In JASPthe programmer can simply embed ASP code in a Java program with-out caring about the interaction with the underlying ASP system. Thisway, it is possible solve seamlessly both tasks suitable for imperative anddeclarative specification as required by RBAC.
Answer Set Programming (ASP) [1] is a fully-declarative logic programmingparadigm proposed in the area of knowledge representation and non-monotonicreasoning. Its idea is to represent a given computational problem by a logicprogram whose answer sets correspond to solutions, and use a solver to find them.After many years of research, the formal properties of ASP are well-understood;notably, ASP is expressive: it can solve problems of complexity beyond NP [4, 5].Moreover, the availability of robust and efficient solvers [8] made ASP an effectivepowerful tool for advanced applications, and stimulated the development of manyinteresting applications [6]. Recently, we have employed ASP for developing someindustrial application, such as: building systems for workforce management [10],e-tourism [3], and solving complex industry-relevant problems [2].The experience we gained has confirmed the viability of the industrial ex-ploitation of ASP. However, it has evidenced the strong need of integratingASP technologies (i.e., ASP programs and solvers) with well-assessed software-development processes and platforms, which are tailored for modern imper-ative object-oriented programming languages [9]. Indeed, the lesson we havelearned, while building real-world ASP-based applications, confirms that com-plex business-logic features can be developed in ASP at a lower (implementation)price than in traditional imperative languages. Indeed, from a software engineer-ing viewpoint, the employment of ASP brings many advantages not only in termsof readability, but also in flexibility, extensibility, and ease of maintenance. How-ever, since ASP is not a fully general-purpose language, declarative specificationshave to be “embedded”, at some point, inside imperative modules that are nec-essary to develop user-friendly applications making use, for example, of visualuser-interfaces. To this end, we have introduced a new programming frameworkintegrating ASP with Java [7]. The framework is based on a hybrid language,
Appendix D alled JASP, that transparently supports a bilateral interaction between ASPand Java. The programmer can simply embed ASP code in a Java program with-out caring about the interaction with the underlying ASP system. The logicalASP program can access Java variables, and the answer sets, resulting from theexecution of the ASP code, are automatically stored in Java objects, possiblypopulating Java collections, transparently. In this section, we sketch a JASP-based solution to the Role-Based Access Con-trol (RBAC) challenge. According to JASP’s philosophy, we associate a Javaclass to each RBAC-set occurring in the five components. Then, we define a class
Manager to implement all methods performing updates and queries from check-ing to planning. In what follows, we report the implementation of method trans —computing the transitive closure of role hierarchy (encoded via relation rh )unioned with the reflexive role (encoded via relation role ) pairs— to appreciatethe succinctness and elegance of the approach: public List
OUT , thatit will host —after the subsequent three ASP rules will have been evaluated—all tuples of predicate tr , which occurs in the head of those ASP rules. Then, weuse the keyword IN to specify that all roles in the Java object jrole (resp., jrh )will populate the EDB predicate role (resp., rh ) used in the body of the first(resp., second) ASP rule to “feed” the answer set computation. Other functionsof the challenge can be developed similarly.The same applies to getRolesShortestPlan , the hardest function in the chal-lenge. In particular, we drafted an encoding that combines: ( i ) functional terms to encode in a uniform way different kind of updating actions given as input; ( ii ) arithmetic operators to design a “temporal” encoding involving at most 2 n up-dating steps, where n is the number of possible actions; ( iii ) disjunction to guess,at each step, the next action; ( iv ) aggregates , negation and strong constraints See http://lpop.cs.stonybrook.edu/preparing-your-position-paper o guarantee consistency after each update; and ( v ) weak constraints to mini-mize the number of steps. A more complete description of all solutions can bedownloaded from .Finally, database-oriented features as well as data persistence can be also addedby integrating a standard RDBMS in the application. Indeed, update functionscan be implemented via DML statement in SQL, and the evaluation of the pre-scribed constraints can be specified as ASP rules inside Java function and theexecution (if needed) can be delegated to the DBMS integrating DLV DB [11]. Concluding remarks.
JASP allows to combine in the same environment main-stream technologies for developing applications and ASP. This allowed us tomodel RBAC Challenge problems and obtain quite rapidly a prototype system. Of course, obtaining a “real”, complete and also efficient solution, which takesinto account also other real-world nonfunctional and functional requirements,would very likely require to adopt more advanced coding strategies and addi-tional tools (e.g., to develop a graphical interface or a WEB service).
References
1. Brewka, G., Eiter, T., Truszczynski, M.: Answer set programming at a glance.Commun. ACM (12), 92–103 (2011)2. Dodaro, C., Gasteiger, P., Leone, N., Musitsch, B., Ricca, F., Schekotihin, K.: Com-bining answer set programming and domain heuristics for solving hard industrialproblems. TPLP (5-6), 653–669 (2016)3. Dodaro, C., Leone, N., Nardi, B., Ricca, F.: Allotment problem in travel industry:A solution based on ASP. In: In proc. of RR’15. pp. 77–92 (2015)4. Eiter, T., Gottlob, G.: Expressiveness of stable model semantics for disjuncitvelogic programs with functions. J. Log. Program. (2), 167–178 (1997)5. Eiter, T., Gottlob, G., Mannila, H.: Disjunctive datalog. ACM Trans. DatabaseSyst. (3), 364–418 (1997)6. Erdem, E., Gelfond, M., Leone, N.: Applications of answer set programming. AIMagazine (3), 53–68 (2016)7. Febbraro, O., Leone, N., Grasso, G., Ricca, F.: JASP: A framework for integratinganswer set programming with java. In: In proc. of KR’12 (2012)8. Gebser, M., Maratea, M., Ricca, F.: The sixth answer set programming competi-tion. J. Artif. Intell. Res. , 41–95 (2017)9. Leone, N., Ricca, F.: Answer set programming: A tour from the basics to advanceddevelopment tools and industrial applications. In: In proc. of Reasoning Web’15.pp. 308–326 (2015)10. Ricca, F., Grasso, G., Alviano, M., Manna, M., Lio, V., Iiritano, S., Leone, N.:Team-building with answer set programming in the gioia-tauro seaport. TPLP (3), 361–381 (2012)11. Terracina, G., Leone, N., Lio, V., Panetta, C.: Experimenting with recursive queriesin database and logic programming systems. TPLP (2), 129–165 (2008) Two 1st year PhD students dedicated about two weeks to the project, including thetime to study the challenge and the JASP framework. On the technical side theywere advised by maintainer of JDLV. he RBAC challenge in the KB-paradigm Marc Denecker Jo DevriendtDepartment Computer Science, KU Leuvenfi[email protected] 25, 2018
The RBAC challenge paper of the LPOP workshop [6] describes a dynamicsystem for role based access control. In this dynamic system, new users, rolesand permissions are added dynamically, or existing ones are deleted. Users areassigned new roles or are stripped of them; roles are assigned new permissions orstripped of them. Roles are organized in hierarchies that may change over time.Users can pose queries. Optimized configurations of role assignments may haveto be computed. Plans must be searched to realize goal configurations; selectedplans must be executed. The goal of the challenge is to build a software systemthat implements this dynamic system and various functionalities in it.In this position paper, we take a theoretical perspective on the problem. Thequestions we asked ourselves initially were of the following kind: how much ofthe RBAC domain can be formally specified in the logic FO(.) (First Order logicextended with inductive/recursive definitions and aggregates) [3]? How much ofthe RBAC system can be analyzed on the basis of the formal specification? Howmuch of the functionalities of the RBAC system can be executed on the basis ofthe formal specification? What forms of inference are needed for that? Someof these questions pertain to the fundamental goals of the scientific domainof Declarative Knowledge Representation. Simple as the RBAC challenge is,we didnot know the answers at the start of this project and some questionsremained unanswered at the end.Our exercise fits in the context of what we called the
Knowledge BaseParadigm [4, 9]. It is the idea that all problem solving is based on domainknowledge, but domain knowledge itself is inherently independent of the com-putational problem; formal specifications of it can be reused to solve a range ofproblems in the application domain. The goal of this experiment is to test thisidea in the RBAC challenge: to build one formal specification, one knowledgebase (or, well, as few as possible), and to reuse them in various inference prob-lems to provide a maximal range of functionalities. We investigated how muchcan be implemented/prototyped with the knowledge base system IDP [2].1
Appendix E ur exercise is theoretical in the sense that we ignore the main metric in com-putational logic and Knowledge Representation research: efficiency/scalability.Nevertheless, we found the exercise interesting and thought provoking and wehope others will think the same. As such, we hope this paper provides somematerial for discussion for the LPOP workshop. New questions that we hopecan be addresed during the workshop are: where is the expertise to derive soft-ware systems from formal specifications? , what are the best formal specificationlanguages for domains such as RBAC and others? , what are the leading systemsand technologies to achieve these goals? , what further research is needed? The vocabulary
An essential step in KR is the design of the formal vo-cabulary and its informal interpretation. It should be designed to express therelevant concepts of the application domain, at the right level of abstraction. Inthis experiment, this step was trivial since all important concepts are explicitlystated in the RBAC challenge paper [6]. The vocabulary is available in theappendix C as vocabulary V RBAC . The theory
We expressed the RBAC dynamic domain in the logic FO(Types,ID,Agg),as much as conveniently possible. This is First Order logic, extended with in-ductive/recursive definitions and agregates [7]. Below, we denote this logic asFO(.). Since FO(.) is not a temporal logic, the dynamics of the domain needs tobe explicated in the vocabulary and the theory. For this we use the methodol-ogy of Linear Time Calculus (LTC) [1], a simplified version of the event calculuswhich uses the natural numbers as a diskrete time line. The LTC methodologyintroduces some fixed overhead: explicit time arguments for action and flu-ent (=state) symbols; frame axioms for all fluent symbols f ( ArgT ypes, T ime ),expressed in terms of 3 auxiliary predicates per fluent: • IN IT f ( ArgT ypes ) to express the initial state of f ; • C f ( ArgT ypes, T ime ) to express when f is caused to be true. • CN f ( ArgT ypes, T ime ) to express when f is caused to be false. Theprefix “CN” stands for “Causes Not”.Also, standard actions of adding and deleting fluent atoms need to be specified.More than 80% of the specification is boiler plate overhead which in a specialpurpose dynamic specification language could and should be avoided.The main components of the theory are: • recursive definitions of fluents expressing inertia and how actions influencefluents. It contains inertia rules such as: ∀ x, t : U SERS ( x, N ext ( t )) ← U SERS ( x, t ) ∧ ¬ CN U SERS ( x, t ) . nd causal rules such as: ∀ x, t : CN U SERS ( x, t ) ← Delete U SERS ( x, t ) . which expresses that the delete action causes ¬ U SERS ( x ) to become true; • action preconditions; e.g., to express that new user-role relations may beadded only for active users and roles: ∀ x, r, t : Add U R ( u, r, t ) ⇒ ¬ U R ( u, r, t ) ∧ U SERS ( u, t ) ∧ ROLES ( r, t ) . • definitions of several derived concepts: e.g., U serP ermission ; HU R whichrelates users with all the roles in the role hierarchy that they possess; • concurrency axioms constraining simultaneous execution of actions.A full theory is specified in Appendix C. Transactions that were not specified
There are also transactions of theRBAC software system that are not and could not (conveniently) be formalized in the theory. All transactions that take a logic expression as input were notformally specified: the operations of querying, planning, plan execution andoptimisation take expressions as input. E.g., the query operation takes as inputa query expression and returns as output the value of this expression in thecurrent state. E.g., this expression could be a set-expression, and its value aset. The problem is that FO(.) lacks the expressivity to ( conveniently ) express afunction from expressions to their value in the underlying structure. To expressthis in the logic, meta-facilities are required and they are not available in FO(.).The same argument holds for planning (the goal) and for optimisation (the costfunction).The absence of specification of these transactions in the formal theory ofRBAC is a striking gap in the theory. However, it does not mean that thesetransactions cannot be executed using logical inference methods. This is dis-cussed in the next section. But what it entails is, for instance, that any formalanalysis of the RBAC theory, e.g., for proving invariants, is partial: it does nottake into account the missing transactions. The essence of the specification
The declarative information in the RBACchallenge is quite limited. The essential information is in the definitions andin the invariants. The definitions are of the transitive closure
T ransHR of therole hierarchy, the user roles
HU R in the hierarchy, and the user permissions
U serP ermission . This amounts to: /* Definitions */{ ! x[Role], y[Role], t[Time] : TransRH(x,y,t) <- RH(x,y,t).! x, y, t : TransRH(x,y,t) <- ?z: RH(x,z,t) & TransRH(z,y,t).} ! u[User], r[Role], t[Time]: HUR(u,r,t) <- UR(u,r,t).! u, r, t: HUR(u,r,t) <- ?r1: UR(u,r1,t) & TransRH(r,r1,t).}{ !u[User], p[Perm], t[Time]: UserPermission(u,p,t) <-?r: HUR(u,r,t)) & PR(p,r,t).}/* Invariants */! u, r, t: UR(u,r,t) => USERS(u,t) & ROLES(r,t).! p, r, t: PR(p,r,t) => PERMS(p,t) & ROLES(r,t).! r, r1, t: RH(r,r1,t) => ROLES(r,t) & ROLES(r1,t).! t: ~? r: TransRH(r,r,t).! ssd, r, t: SSD_ROLES(ssd,r,t) => ROLES(r,t).! u, ssd[SSD], t: This theory ( ± ) is presented in Appendix A. All the rest of the theory isboiler-place and can be generated automatically. One obtains a theory as inappendix C. Or, in a suitable dynamic logic derived from FO(.), the extrarules and assertions would be implicit in the semantics of the language. Inparticular, for each fluent, the frame axioms, the add and delete actions and theirpreconditions are similar in all cases and, in a dynamic logic, should be implicit.All functionalities specified in the RBAC challenge paper can be derived bygeneric inference on the completed theory. We discuss how in the next section. Remark
Regarding the suitability of our logic for real world applications,if we forget about the boiler plate which evidently must be eliminated, ourspecification is simple to understand, compact, and contains no redundancy:every aspect that was formalized needs to be formalized.A feature of a formal specification in LTC is that it is state-oriented: trans-actions are atomic actions. The same is true in many dynamic specificationlanguages. One problem that we see with, e.g., the optimization transactionor the planning transactions in RBAC is that, in practice, these operationsare not atomic but they are processes involving user interaction. At the veryleast, the user needs to make a selection out of the possible reconfigurationsor plans. Thus, a specification language may need to support the concept ofprocess. Standard imperative or object oriented languages are strongly processoriented. Surely, this has sometimes its disadvantages as well. E.g., such processdescriptions often impose unnecessary constraints on the order of execution ofactions. So, one question that rises here is the issue of how to formally specify4 rocesses, whether or when state-oriented versus process-oriented is best, andhow to combine the best of worlds. Analysis: Verification of invariants
The theory
T RBAC Pre in Appendix Cspecifies action preconditions. E.g., that a new edge ( r , r ) can be added tothe role hierarchy RH only if r is not higher in the hierarchy than r . This isto avoid that cycles are created in the hierarchy.The RBAC challenge paper [6] mentions a set of invariants of RBAC. E.g.,roles assigned to users need to be in the set ROLES of active roles, and can beassigned only to elements of the set
U SERS of active users. Others are implicit,e.g., there are no cycles in the role hierarchy. They are described above. Theyare the elements of the theory invariant in the appendix C.One analysis task for the specification is to check if
T RBAC Pre entails invariant . This is a deduction problem over the inductively defined set ofnatural numbers (
T ime ). Using a standard technique, this problem can (often)be reduced to determining unsatisfiability of the following theory:
T RBAC Pre bs + invariant ( ) + ¬ invariant ( )Here, T RBAC Pre bs is the bistate theory , the part of theory
T RBAC Pre express-ing the relationship between two successive states, named 0 , invariant (0) and ¬ invariant (1) express that the invariants are satisfied at 0 and not at 1. If thistheory is unsatisfiable, then any process starting from an initial state satisfying invariant (0) preserves the invariants.The theory T RBAC Pre contains an inductive definition of
TransRH thatcannot be expressed in predicate logic. To the best of our knowledge, thereare currently no theorem provers for predicate logic augmented with inductivedefinitions . The IDP system supports a light weight version: it can verify thesatisfiability in the context of fixed finite domain. It is nevertheless useful. Thatis, the small scope hypothesis works fine in many cases: errors in the specificationoften do emerge in small domains.We performed this analysis with IDP. At first, we assumed a no concur-rency axiom, excluding the presence of multiple simultaneous actions. Theanalysis brought a few forgotten preconditions to the surface: namely that noelement of U SERS, ROLES, P ERM S may be be deleted when still in use in
U R, P R, RH, SSD Roles .In a second step, we analyzed concurrent execution of actions (dropping noconcurrency ). The analysis showed that with concurrency, all action precondi-tions need to be strengthened. So that, e.g., it is not possible to simultaneouslyadd a role to user u and delete u of
U SERS . The action preconditions becomequite complex then. However, (1) the action preconditions can be computed au-tomatically from the invariants by the principle of regression [8]; (2) by adding Entailment of predicate logic with inductive definitions is not decidable, not even semi-decidable. he invariants to the theory, combinations of actions that violate invariants canbe detected by satisfiability checking. Thus, if the goal of an action precondi-tion is merely to safeguard the invariants, there is no need for it: a suitabletransaction engine will be able to accept or reject a proposed transaction on thebasis of an LTC theory including the invariants. Thus, we can greatly simplifythe theory. The appendix A contains the theory from which all boiler-plate wasremoved. It is the input of the IDP-solution.We observe that not every action precondition serves to protect an invariant.E.g., an action precondition for the operation of adding x to a fluent is that x is not an element already of the fluent. This action precondition is not relatedto an invariant. Executing updates for RBAC
The RBAC challenge specifies a dynamictransactional system with persistent data and updates through add and deleteoperations. We here describe how, in theory, the updates could be derived fromthe formal specification.For simplicity, we assume that times and dates are associated with naturalnumbers. E.g., 3:35pm on 18/7/2018 is associated with the total number ofseconds that has passed since 0:00am of 1/1/1980.Given an LTC theory T , we define a state theory at time n ∈ IN as a theoryconsisting of the following components: • the theory T , extended with • equation now = n , where now is a logical constant informally interpretedas the current time; • an exhaustive description of the initial values of all fluents; • an exhaustive description of the set of actions that occur at time points t ≤ n (i.e., in the past of now ). E.g., in FO(.), the actions could bedescribed by: Add U SERS ( u, t ) ← F uture Add U sers ( u, t ) ∧ t > now.Add U SERS ( J im, / / ,
10 : 31 am ) .Add U SERS ( Sarah, / / ,
15 : 02 pm ) .. . . h set of add operations to U SERS in the past of now i This definition expresses a local closed world assumption on Add U SERS ,for the past of now . Here, the predicate
F uture Add U sers represents theunknown future
Add U SERS transactions.An evolution of the RBAC software system corresponds to an evolution of statetheories. At each time point n , the state of the software system correspondsto a state theory at n . This state theory represents the epistemic state of theapplication: what it knows and does not know. With an update at time n , anew state theory corresponds which is obtained by extending the previous onewith actions at time n . E.g., if Dave is added as a user on 18/6/2018 12am,6 he above definition is extended with Add U SERS ( Dave, / / , am ) . .With time, the state theory accumulates more information about the world, inparticular about the past of now . At no point in time, the state theory knows thefuture of now . There is a monotonicity property: the class of models/possibleworlds of state theories decreases monotonically with time until, at infinity, itbecomes categorical and has only one model: the history as it happened. Sincethe class of possible worlds decreases, the knowledge increases. There is oneaspect that is non-monotonic though: with time, the value of now changes andthis is a non-monotonic change. I.e., with time the application changes its mindabout what is the current time. Even when nothing happens for a while, theapplication accumulates extra knowledge: that no change happened. Of course,the meta-operations (e.g., the queries and planning operations) are not andcannot be registered in the state theory.Conceptually, to verify if the action preconditions and concurrency axiomsare satisfied by a proposed update, the update is inserted in the state theoryand the theory is verified for satisfiability. If the state theory is satisfiable, theupdate is accepted and the state theory is stored. Otherwise, the update isrejected and the state theory remains unchanged (except for the new value of now ).For a practical implementation of the above theoretical procedure, manyoptimizations are possible and necessary. For example, the satisfiability of theaction preconditions of an update at time now = n can be computed using the current state structure : the state at time now . Implementation-wise, it makessense to explicitly store this structure. If the transaction is accepted, the currentstate structure can be progressed to the new current state [5, 1]. The currentstate structure is useful as well to answer what will probably be the bulk of thequeries, namely queries about the current state. Solving current state queries and temporal queries
A state theory attime n determines two structures: the current state structure I Cur , expressingall fluents and actions at time now = n , and the past state structure I P ast , ex-pressing all fluents and actions for the interval [0 , n ]. The current state structureis a structure of the single state vocabulary : this is the vocabulary from whichtime is projected out from fluents and actions.Queries over the current state can be expressed as a set expression, or aformula or a function term in the single state vocabulary. An example is: { u [ U ser ] : { p [ P erm ] :
U serP ermission ( u, p ) } ≥ } It expresses the set of users that have at least 4 permissions in the current state.Temporal queries generalize current state queries. E.g., this current statequery can be expressed as the temporal query: { u [ U ser ] : { p [ P erm ] :
U serP ermission ( u, p, now ) } ≥ } Temporal queries over the past can be expressed as expressions of the same sortover the original vocabulary. E.g., the following query is whether there is a user7 hat once had a permission to “write”, lost it and then regained it: ∃ u : ∃ t , t , t t < t < t < now ∧ U serP ermission ( u, W rite, t ∧¬ U serP ermission ( u, W rite, t ∧ U serP ermission ( u, W rite, t Planning and plan execution
For this problem of the RBAC challenge, thegoal is to compute a series of updates to transform the current state into a goalstate satisfying a formula Ψ[ t ]. In a next phase, if the user accepts the computedplan, the plan has to be executed.The planning inference problem takes as input the current state theory andthe goal formula ∃ t : t ≥ now ∧ Ψ[ t ]. Its output is representable as an exhaustiveenumeration of add and delete actions in some interval [ now, t end ] so that thestate theory extended with it is satisfiable and entails Ψ[ t end ].In practice, this problem can be solved using iterated model expansion. Thisis a well known approach in SAT for planning and in answer set programming.The search is for a model of the current state theory augmented Ψ[ now + N ]. N is incremented until a model is found.At this theoretical level, “execution” of the plan boils down to add theactions in the time interval [ now, now + N ] in this model to the state theory.In reality, there is much more to do. E.g., execution of plans with actions thatchange the external world have to be monitored since they may fail. Here wewill ignore this problem.As explained above, formally specifying the planning transaction in the de-scription of the dynamic system requires meta-facilities in the underlying logic.This does not prevent us from specifying the transaction at the proceduralmeta-level, using o.a. a call to a planning inference engine. Optimizing the configuration
The last problem of the RBAC challengeconsidered here is to reconfigure the base relations
U R, P R, RH : determineminimal values for these relations such that all users maintain exactly the samepermissions as in the current state.This problem can be specified as the following inference problem. It takesas input the definition of
U serP ermission/
2, the current state structure pro-jected on the symbols
U SERS, ROLES, P ERM S and
U serP ermission/
2, andfinally a cost function specifying that the sum of the cardinality of the relations
U R, P R, RH is minimal. The output is a value for
U R, P , RH in a model thatminimizes the cost function. This is an application of optimization inference .We observe that the input of the problem contains both a value and an(inductive) definition for U serP ermission . Thus, the model generator needs to8 nd values for the parameters of this definition such that the value determinedby the definition corresponds to the given value.The final step is to bring the database in the optimized state. This problemcan be reduced to the application of the planning and plan execution procedure. We implemented a prototype system in IDP. It supports base versions of allthe requested functionalities of the challenge. The system has a persistent staterepresented as a state theory. Implemented operations are: verification of in-variants, temporal queries, updates of base relations, planning, execution ofchosen plans, optimization, and planning and executing a choosen optimiza-tion. Our explicit goal was to narrowly implement the theoretical ideas, thatis, to characterize and implement a maximum of functionality and flexibility onthe basis of a minimal, purely declarative specification. The input of the systemis the formal specification provided in the appendix A. All “boiler plate” isautomatically generated from it. A trace file is presented in appendix B. Noneof the optimizations proposed above were implemented. The system handlesonly toy examples. Nevertheless, we expect that with a limited effort, it shouldbe possible to build a system from off-the-shelve tools that can handle smallapplications. The system is available at bitbucket.org/krr/rbac . The contributions of this paper are more in the scientific questions that wepose than in the complexity of the solutions that were offered. The goal ofthis experiment was the following: to check to what extend the RBAC softwaresystem could be implemented by generic inference on a knowledge base/formalspecification. To this aim, we have evaluated the instances for RBAC of somefundamental questions of KR: what parts of the dynamic system can be formallyspecified, what forms of inference are needed to implement the functionalitiesof RBAC.We have seen gaps in the expressivity of the logic (which occur in many, if notall current dynamic logics), namely to express complex transactions that takearguments of type
Expression as input. That does not mean that for executingthem, logic based systems are of no use. The contrary is true. However, itcertainly means that the full RBAC system cannot be formally analyzed, e.g.,proving invariants. It also excludes that the RBAC system as a whole can berun by uniformally applying a fixed form of inference on the specification.All parts of the RBAC challenge can be “implemented” by inference on theformal specification(s). In all of this, the same very limited set of propositionsare used time and again: the definitions of the main concepts (
U serP ermission , HU R , T ransRH ), concurrency axioms, invariants. Beside this, other declara-tive entities such as queries and goals and cost functions need to be expressed9 epending of the problem at hand.There are important functionalities that were not considered. E.g., verifi-cation of temporal logic properties. E.g., revision inference to erase erroneousfacts. For example, assume that in 2011, a non-existing user was accidentallyadded and this is discovered in 2018. References [1] Bart Bogaerts, Joachim Jansen, Maurice Bruynooghe, Broes De Cat, JoostVennekens, and Marc Denecker. Simulating dynamic systems using lineartime calculus theories.
TPLP , 14(4–5):477–492, 7 2014.[2] Broes De Cat, Bart Bogaerts, Maurice Bruynooghe, Gerda Janssens, andMarc Denecker. Predicate logic as a modelling language: The IDP system.
CoRR , abs/1401.6312v2, 2016.[3] Marc Denecker and Eugenia Ternovska. A logic of nonmonotone inductivedefinitions.
ACM Trans. Comput. Log. , 9(2):14:1–14:52, April 2008.[4] Marc Denecker and Joost Vennekens. Building a knowledge base system foran integration of logic programming and classical logic. In Mar´ıa Garc´ıa dela Banda and Enrico Pontelli, editors,
ICLP , volume 5366 of
LNCS , pages71–76. Springer, 2008.[5] Fangzhen Lin and Raymond Reiter. How to progress a database.
Artif.Intell. , 92(1-2):131–167, 1997.[6] Yanhong A. Liu. Role-based access control as a programming challenge.Logic and Practice of Programming workshop, July 18 2018.[7] Nikolay Pelov, Marc Denecker, and Maurice Bruynooghe. Well-founded andstable semantics of logic programs with aggregates.
TPLP , 7(3):301–353,2007.[8] Raymond Reiter.
Artificial intelligence and mathematical theory of computa-tion , chapter The frame problem in situation the calculus: A simple solution(sometimes) and a completeness result for goal regression, pages 359–380.Academic Press Professional, Inc., San Diego, CA, USA, 1991.[9] Pieter Van Hertum, Ingmar Dasseville, Gerda Janssens, and Marc Denecker.The KB paradigm and its application to interactive configuration.
TPLP ,17(1):91–117, 2017. 10 Input RBAC specification (without boilerplate) vocabulary V{extern vocabulary LTCvocTransRH(Role,Role,Time)HUR(User,Role,Time)UserPermission(User,Perm,Time)}theory Invariants:V{/* No concurrency axiom *//* Invariants */!ssd,r,t: SSD_ROLES(ssd,r,t) => ROLES(r,t).! u[User],ssd[SSD],t, c: SSD_Card(ssd,c,t) => ocabulary OptimizeProjection{extern vocabulary Typesextern V::USERS/2extern V::PERMS/2extern V::ROLES/2extern V::now/0:1extern V::UserPermission/3}vocabulary OptimizeGoal{extern vocabulary Typesextern V::UR/3extern V::PR/3extern V::RH/3} B A trace $./reset.sh$./query.sh "{ x : USERS(x,now)}"{ }$./query.sh "{ x : x=now}"{ 1 }$./query.sh "{ x : x=now}"{ 2 }$./update.sh "Add_USERS(u1). Add_USERS(u2). Add_USERS(u3).Add_ROLES(r1). Add_ROLES(r2). Add_ROLES(r3).Add_PERMS(read). Add_PERMS(write). Add_PERMS(modify).Add_UR(u2,r2). Add_UR(u3,r3).Add_PR(write,r1). Add_PR(read,r2). Add_PR(modify,r3).Add_RH(r1,r2). Add_RH(r2,r3)."Update succesful.$./query.sh "{ x p : UserPermission(x,p,now)}"{ u2,read; u2,write; u3,modify; u3,read; u3,write }$./update.sh "Add_USERS(u1)."Warning: given update violates preconditions and is aborted.$./update.sh "Delete_USERS(u1)."Update succesful.$./update.sh "Add_USERS(u1)."Update succesful.$./update.sh " Add_RH(r3,r3)."Warning: given update violates preconditions and is aborted.$./update.sh " Add_RH(r3,r2)."Warning: given update violates preconditions and is aborted.$./query.sh "{ x p : TransRH(x,p,now)}"{ r1,r2; r1,r3; r2,r3 }$./plan.sh "/*all users have all permissions; only one action per time point */! x[User], p1[Perm]: UserPermission(x,p1,maxT) &! t: t>= now => {p, r :Add_PR(p,r,t)}+ C RBAC with action preconditions and with-out concurrency
LTCvocabulary V_RBAC{type Time isa intStart:Timepartial Next(Time):Timetype Usertype Roletype PermUSERS(User,Time)Add_USERS(User,Time)Delete_USERS(User,Time)Init_USERS(User)C_USERS(User,Time)CN_USERS(User,Time)UsedUSERS(User,Time)UsedROLES(Role,Time)UsedPERMS(Perm,Time)ROLES(Role,Time)Add_ROLES(Role,Time)Delete_ROLES(Role,Time) nit_ROLES(Role)C_ROLES(Role,Time)CN_ROLES(Role,Time)PERMS(Perm,Time)Add_PERMS(Perm,Time)Delete_PERMS(Perm,Time)Init_PERMS(Perm)C_PERMS(Perm,Time)CN_PERMS(Perm,Time)UR(User,Role,Time)Add_UR(User,Role,Time)Delete_UR(User,Role,Time)Init_UR(User,Role)C_UR(User,Role,Time)CN_UR(User,Role,Time)PR(Perm,Role,Time)Add_PR(Perm,Role,Time)Delete_PR(Perm,Role,Time)Init_PR(Perm,Role)C_PR(Perm,Role,Time)CN_PR(Perm,Role,Time)UserPermission(User,Perm,Time)/* hierarchical */RH(Role,Role,Time)Add_RH(Role,Role,Time)Delete_RH(Role,Role,Time)Init_RH(Role,Role)C_RH(Role,Role,Time)CN_RH(Role,Role,Time)TransRH(Role,Role,Time)HUR(User,Role,Time) /* AuthorizedRole */HUserPermission(User,Perm,Time)/*SSD*/type SSDtype NrRoles isa intSSD_ROLES(SSD,Role,Time)Add_SSD_ROLES(SSD,Role,Time)Delete_SSD_ROLES(SSD,Role,Time)Init_SSD_ROLES(SSD,Role)C_SSD_ROLES(SSD,Role,Time)CN_SSD_ROLES(SSD,Role,Time)SSD_Card(SSD,Time):NrRolesSet_SSD_Card(SSD,NrRoles,Time) nit_SSD_Card(SSD,NrRoles)C_SSD_Card(SSD,NrRoles,Time)}theory T_RBAC_Pre: V_RBAC{{ ! u,t:UsedUSERS(u,t)<- ?r:UR(u,r,t).}{ ! r,t:UsedROLES(r,t)<- ?u:UR(u,r,t).! r,t:UsedROLES(r,t)<- ?p:PR(p,r,t).! r,t:UsedROLES(r,t)<- ?r1:RH(r,r1,t).! r,t:UsedROLES(r,t)<- ?r1:RH(r1,r,t).! r,t:UsedROLES(r,t)<-? ssd: SSD_ROLES(ssd,r,t). }{ ! p, t :UsedPERMS(p,t)<- ?r:PR(p,r,t).}/*RBAC pure */{ !u: USERS(u,Start) <- Init_USERS(u).!u, t: USERS(u,Next(t)) <- C_USERS(u,t).!u, t: USERS(u,Next(t)) <- USERS(u,t) & ~CN_USERS(u,t).!u,t: C_USERS(u,t) <- Add_USERS(u,t).!u,t: CN_USERS(u,t) <- Delete_USERS(u,t).}! x,t: Add_USERS(x,t) => ~USERS(x,t).! x,t: Delete_USERS(x,t) => USERS(x,t) & ~ UsedUSERS(x,t).{ !r: ROLES(r,Start) <- Init_ROLES(r).!r, t: ROLES(r,Next(t)) <- C_ROLES(r,t).!r, t: ROLES(r,Next(t)) <- ROLES(r,t) & ~CN_ROLES(r,t).!r,t: C_ROLES(r,t) <- Add_ROLES(r,t).!r,t: CN_ROLES(r,t) <- Delete_ROLES(r,t).}! x,t: Add_ROLES(x,t) => ~ROLES(x,t).! x,t: Delete_ROLES(x,t) => ROLES(x,t) & ~ UsedROLES(x,t).{ !p: PERMS(p,Start) <- Init_PERMS(p).!p, t: PERMS(p,Next(t)) <- C_PERMS(p,t).!p,t: PERMS(p,Next(t)) <- PERMS(p,t) & ~CN_PERMS(p,t).!p,t: C_PERMS(p,t) <- Add_PERMS(p,t).!p,t: CN_PERMS(p,t) <- Delete_PERMS(p,t).}! x,t: Add_PERMS(x,t) => ~PERMS(x,t).! x,t: Delete_PERMS(x,t) => PERMS(x,t)& ~ UsedPERMS(x,t).{ !u,r: UR(u,r,Start) <- Init_UR(u,r).!u, r, t: UR(u,r,Next(t)) <- C_UR(u,r,t).!u,r,t: UR(u,r,Next(t)) <- UR(u,r,t) & ~CN_UR(u,r,t). u,r,t: C_UR(u,r,t) <- Add_UR(u,r,t).!u,r,t: CN_UR(u,r,t) <- Delete_UR(u,r,t).}! u,r,t: Add_UR(u,r,t) => ~UR(u,r,t).! u,r,t: Add_UR(u,r,t) => USERS(u,t) & ROLES(r,t).! u,r,t: Delete_UR(u,r,t) => UR(u,r,t).{ !p,r: PR(p,r,Start) <- Init_PR(p,r).!p, r, t: PR(p,r,Next(t)) <- C_PR(p,r,t).!p,r,t: PR(p,r,Next(t)) <- PR(p,r,t) & ~CN_PR(p,r,t).!p,r,t: C_PR(p,r,t)<-Add_PR(p,r,t).!p,r,t: CN_PR(p,r,t)<-Delete_PR(p,r,t).}! p,r,t: Add_PR(p,r,t) => ~PR(p,r,t).! p,r,t: Add_PR(p,r,t) => PERMS(p,t) & ROLES(r,t).! p,r,t: Delete_PR(p,r,t) => PR(p,r,t).{ !u,p,t: UserPermission(u,p,t) <- ?r: UR(u,r,t) & PR(p,r,t).}/* Hierarchical */{ !r,r1: RH(r,r1,Start) <- Init_RH(r,r1).!r,r1, t: RH(r,r1,Next(t)) <- C_RH(r,r1,t).!r,r1, t: RH(r,r1,Next(t)) <- RH(r,r1,t) & ~CN_RH(r,r1,t).!r,r1,t: C_RH(r,r1,t)<-Add_RH(r,r1,t).!r,r1,t: CN_RH(r,r1,t)<-Delete_RH(r,r1,t).}! r,r1,t: Add_RH(r,r1,t) => ~RH(r,r1,t).! r,r1,t: Add_RH(r,r1,t) => ROLES(r,t) & ROLES(r1,t) & r~=r1.! r,r1,t: Add_RH(r,r1,t) => ~TransRH(r1,r,t).! r,r1,t: Delete_RH(r,r1,t) => RH(r,r1,t).{ ! x,t : TransRH(x,y,t) <- RH(x,y,t).! x,y,t : TransRH(x,y,t) <- ?z: RH(x,z,t) & TransRH(z,y,t).}{ ! u,r,t: HUR(u,r,t) <- ?r1: UR(u,r1,t) & TransRH(r,r1,t).}{ !u,p,t: HUserPermission(u,p,t)<- ?r: (UR(u,r,t) | HUR(u,r,t)) & PR(p,r,t).}/* SSD */{ !ssd,r: SSD_ROLES(ssd,r,Start) <- Init_SSD_ROLES(ssd,r).!ssd,r, t: SSD_ROLES(ssd,r,Next(t)) <- C_SSD_ROLES(ssd,r,t).!ssd,r,t: SSD_ROLES(ssd,r,Next(t)) <- SSD_ROLES(ssd,r,t) & ~CN_SSD_ROLES(ssd,r,t).!ssd,r,t: C_SSD_ROLES(ssd,r,t) <- Add_SSD_ROLES(ssd,r,t).!ssd,r,t: CN_SSD_ROLES(ssd,r,t) <- Delete_SSD_ROLES(ssd,r,t).} ssd,r,t: Add_SSD_ROLES(ssd,r,t) => ~SSD_ROLES(ssd,r,t).! ssd,r,t: Delete_SSD_ROLES(ssd,r,t) => SSD_ROLES(ssd,r,t).{ !ssd,c: SSD_Card(ssd,Start)=c <- Init_SSD_Card(ssd,c).!ssd,c, t: SSD_Card(ssd,Next(t))=c <- C_SSD_Card(ssd,c,t).!t,ssd: SSD_Card(ssd,Next(t))=SSD_Card(ssd,t) <- ~? c: C_SSD_Card(ssd,c,t).!t,ssd,c: C_SSD_Card(ssd,c,t)<- Set_SSD_Card(ssd,c,t).}! u[User],ssd[SSD],t: he RBAC challenge in LogiQL: Solutions and Limitations K. Tuncay Tekle, Stony Brook University [email protected]
June 28, 2018
LogicBlox [1] is a commercial system unifying the programming model for enterprise software developmentthat combines transactions with analytics by using a flavor of Datalog called LogiQL. LogiQL is a strongly-typed, extended form of Datalog that allows coding of entire enterprise applications, including business logic,workflows, user interfaces, statistical modeling, and optimization tasks.The programming challenge for the Logic and Practice of Programming workshop is based on Role-BasedAccess Control (RBAC) [2], and provides various problems whose solutions require the handling of (1) rules,(2) queries, (3) updates, (4) type constraints, (5) other constraints, (6) optimization, (7) planning. In thispaper, we show that problems related to the first five can be completely handled, one case of optimizationcan be handled with some caveats, and another can be written but does not run in the latest implementation;and planning cannot be handled in LogiQL.As an overview, LogicBlox is a state-based system with a persistent database that can be manipulated,where one can add facts to the database, and rules and constraints to the state, and query the databaseat any point in time. Rules and queries are readily handled by a logic programming system as expected.Type constraints are also intrinsic to LogiQL as every predicate is typed. Constraints that are not typeconstraints in this challenge can also be intuitively expressed. All of these are maintained in the presence ofupdates. Optimization problems can also be handled, although we show that it requires a rewrite to fit in theoptimization framework, and has some restrictions. There is no capability for planning in LogiQL, howeverwe propose a syntax similar to optimization that requires an implementation. However, since LogicBlox is aclosed-source system, we do not expect that this would be implemented.
We briefly introduce how LogicBlox works, and how it evaluates LogiQL. In LogicBlox, the system startswith an empty state, where a state contains the fact database, rules and constraints. The state can bemanipulated by adding facts, rules or constraints, where more facts can be added automatically by therules due to the addition of facts, or the manipulation can be rejected due to the added facts not satisfyingconstraints.The programming system can be separated into three components: (1) installed blocks, (2) updates,(3) queries. Installed blocks contain entity and predicate declarations, rules, and constraints. Updates areinserts, updates or deletes to entities or predicates. Queries retrieve data from predicates or may introducea temporary rule to retrieve data. A sketch of how LogicBlox evaluates LogiQL as follows: (1) when a newblock is installed, all declarations in the block are installed, all rules in the block are evaluated bottom-upwith respect to the current state of the database, and all constraints are checked; if a constraint fails, theinstallation of the block is rolled back; (2) for an update: all rules in all installed blocks are evaluatedbottom-up (incrementally whenever possible), then all type constraints are enforced by deleting facts ofa predicate related to an entity if that entity is deleted in an update, then if any other constraint is notsatisfied after the evaluation of the rules, the update is rolled back; (3) for a query, the results of the queryare retrieved as expected. 1
Appendix F ext, we dig in to the components of RBAC, where we talk about only new concepts needed for eachcomponent in order. The code for each component can be found in the appendix. Entity declarations and updates.
This component first defines some types: Users, roles, and permis-sions. Types are called entities in LogiQL, and entities can be implemented via entity and refmode (referencemode) declarations. A user can then be added using update statements. All of the update functions for theseentities (
AddUser, DeleteUser, AddRole, DeleteRole, AddPerm, DeletePerm ) can be implemented us-ing the entity declarations and update statements.
Relation declarations and updates.
Next, user-role pairs, and permission-role pairs are introduced withthe constraint that each set of pairs is a subset of the cross-product of the entities. This is trivially satisfiedin LogiQL by the nature of the declaration of the set of pairs, where each argument’s type is provided bya constraint. Therefore, e.g., any insert to a predicate verifies that the types of its arguments matches thedeclaration, or else the update fails. If an entity of a type is removed, all predicate facts related to thatparticular entity is removed as well. All of the update functions for these relations (
AddUR, DeleteUR,AddPR, DeletePR ) can be implemented using these declarations.
Queries.
All three queries in this component are easily implemented via logical queries.
Rules.
Reflexive-transitive closure of the role hierarchy can be defined via rules.
Complex constraints.
So far we have only seen type constraints. More complex constraints can besimilarly implemented via the right arrow notation. For example, the acyclicity of the role hierarchy can beenforced by constraints.
SSD can be implemented using the concepts introduced above, and the hieararchical version only needs tochange the predicate to use the Hierarchical RBAC version rather than the Core.
There are two types of new challenges in this component: optimization and planning. There is no planningfunctionality in LogiQL, and optimization has restrictions. We show how to solve the
MinRoleAssignments and
MinRoleAssignmentsWithHierarchy optimization problems with caveats, and suggest a syntax forplanning.
Optimization.
In LogiQL, optimization is performed by translating the rules and variables into a math-ematical program. Therefore, the variables and the predicate to solve for need to be defined, and thereare various restrictions on what the rules and constraints can look like. Then, the mathematical problemis solved via an invocation of a solver using the facts of the current state. Note that this is significantlydifferent than how the system normally operates.For the hierarchical version of the problem, the definition of rules needs to be recursive. However,the preprocessor fails at translating the rules written this way, although a mapping seems obvious for thisexample.
Planning.
Planning problems in Administrative RBAC cannot be specified in LogiQL, but the lack of animplementation (and the possibility of it being implemented being close to zero) notwithstanding, it is notdifficult to imagine that directives such as the ones used in optimization could be used to construct actionvariables based on each action that can be taken, and a solver variable for the objective.2 eferences [1] Aref, M., ten Cate, B., Green, T. J., Kimelfeld, B., Olteanu, D., Pasalic, E., Veldhuizen,T. L., and Washburn, G.
Design and implementation of the logicblox system. In
Proceedings of the2015 ACM SIGMOD International Conference on Management of Data, Melbourne, Victoria, Australia,May 31 - June 4, 2015 (2015), T. K. Sellis, S. B. Davidson, and Z. G. Ives, Eds., ACM, pp. 1371–1382.[2]
Liu, Y. A.
Role-based access control as a programming challenge. In
Logic and Practice of ProgrammingWorkshop (2018).
A Core RBAC • Definition of Users, Roles, Permissions (types):
User(u), UserName(u:n) -> string(n).Role(r), RoleName(r:n) -> string(n).Permission(p), PermissionName(p:n) -> string(n). • Addition/removal of a user (update): +UserName[_] = "tuncay".-UserName[_] = "tuncay". • Definition of user-role, permission-role pairs (relations):
UR(u,r) -> User(u), Role(r).PR(p,r) -> Permission(p), Role(r). • Addition/deletion of user-role, permission-role pairs (update): +UR(u,r) <- UserName[u] = "tuncay", RoleName[r] = "admin".-PR(p,r) <- PermissionName[u] = "write", RoleName[r] = "admin". • AssignedRoles, UserPermissions, CheckAccess queries: _(r) <- UserName[u] = "tuncay", UR(u,r)._(p) <- UserName[u] = "tuncay", UR(u,r), PR(p,r)._(true) <- UserName[u] = "tuncay", PermissionName[p] = "read", UR(u,r), PR(p,r).
B Hierarchical RBAC • Role hierarchy definition:
RH(r1,r2) -> Role(r1), Role(r2). • Definition of the reflexive-transitive closure of the role hierarchy, and
AuthorizedRoles (rules):
Trans(r1,r1) <- Role(r1).Trans(r1,r2) <- RH(r1,r2).Trans(r1,r2) <- RH(r1,r3), Trans(r3,r2).AuthorizedRoles(u,r1) <- UR(u,r), Trans(r,r1). • Enforcement of the acyclicity of the role hierarchy (constraint):
Trans(p,p2), Trans(p2,p) -> p = p2. Static Separation of Duty • Declarations of types and relations:
RoleSet(rs), RoleSetName(rs:n) -> string(n).RoleSetRoles(rs,r) -> RoleSet(rs), Role(r).SSDItem(s), SSDItemName(s:n) ->string(n).SSDItemRoleSet[s] = rs -> SSDItem(s), RoleSet(rs).SSDItemCardinality[s] = c -> SSDItem(s), int(c).SSDItem(s) -> SSDItemRoleSet[s] = _.SSDItem(s) -> SSDItemCardinality[s] = _. • Deletion of an
SSDItem : -SSDItem[s], -RoleSet(rs) <- SSDItemName@prev[s] = "s1", SSDItemRoleSet@prev[s] = rs. Note here the use of @prev on the right hand side of the rule. For an update of a predicate that dependson a fact of that predicate before the update starts, this annotation is utilized to avoid recursion. Sothis rule says if there is an SSD item with the name s1 before the update is started, then delete thatSSD item. • Adding/deleting role sets, updating cardinality: +RoleSetRoles(rs,r) <- SSDItemName[s] = "s1", SSDItemRoleSet[s] = rs.-RoleSetRoles(rs,r) <- SSDItemName[s] = "s1", SSDItemRoleSet[s] = rs, RoleName[r] = "r1".^SSDItemCardinality[s] = c <- SSDItemName[s] = "s1".
The ^ symbol indicates an update of an existing functional value. We need to define the number ofitems in a role set to support the constraints as follows. • Constraints for the role count and cardinality relations:
RoleCount[s] = rc -> SSDItem(s), int(rc).RoleCount[s] = rc <- agg<
UserSSDRoleCount to use
AuthorizedRoles instead of UR . 4 Administrative RBAC
For the first problem,
MinRoleAssignments , the total size of new
UR’ and
PR’ need to be minimized; however
ROLES’ can also contain new roles. There is no way to invent new values during optimization in LogiQL.Therefore, we restrict the question so that
ROLES’=ROLES . Then, we first define two predicates which definewhether a role subsumes another and the original permissions.
Subsume[r1,r2] = b -> Role(r1), Role(r2), int(b).Subsume[r1,r2] = 1 <- Trans(r1,r2).OrigPerms[u,p] = b -> User(u), Permission(p), int(b).OrigPerms[u,p] = 1 <- AuthorizedRoles(u,r), PR(r,p).
Then, we define the new variables and constraints for the optimization problem as follows, where
NewPerms are the user-permissions based on the
NewUR and
NewPR sets which are self-explanatory:
NewUR[u,r] = b -> User(u), Role(r), int(b), b >= 0, b <= 1NewPR[p,r] = b -> Permission(p), Role(r), int(b), b >= 0, b <= 1.lang:solver:variable(‘NewUR).lang:solver:variable(‘NewPR).NewPerms[u,p] = b -> User(u), Permission(p), int(b), b >= 0, b <= 1.NewPerms[u,p] = b1, OrigPerms[u,p] = b2 -> b1 = b2.NewPerms[u,p] = b1, !OrigPerms[u,p] = _ -> b1 = 0.NewPerms[u,p] = v, NewUR[u,r1] = v1, Subsume[r1,r2] = v2, NewPR[p,r2] = v3 -> v >= v1 * v2 * v3.
The directive lang:solver:variable defines the variables of the optimization problem. Finally, we definethe optimization function as follows:
NewURSize[] = nus <- agg<
The directive lang:solver:minimal defines the predicate to solve for (by way of minimization).5 ogic-based Methods for Software Engineers andBusiness People Joost Vennekens
KU Leuven, Dept. of Computer ScienceCampus De Nayer, St-Katelijne-Waver, Belgium
Abstract.
Both software engineers and business people tend to be re-luctant to adopt logic-based methods. On the one hand, this may be dueto unfamiliarity with “scary” logical syntax. To ameliorate this, we de-veloped an API for a state-of-the-art logic system, using only standardPython syntax. On the other hand, logic-based methods might have moreimpact if they could be used directly by business people. The recent DMNstandard that might help in this respect.
Logic-based methods have great potential to improve current software engineer-ing practice. However, this potential is often not evident for people from in-dustry. For instance, when demoing a state-of-the-art knowledge base system toprogrammers, we typically get comments stating that, e.g., they can programthe same functionality with “a couple of for-loops”. To properly appreciate thebenefits of a logic-based approach (greater flexibility, modularity, reliability andmaintainability), it is necessary to understand in detail how the representationworks, at least in the context of a small example. Here, syntax often seems abottleneck, with programmers getting hung up on details they dislike.To reduce this effect, we developed an API [3] that allows the state-of-the-art IDP knowledge base system [1] to be used from the Python programminglanguage. Crucially, this API allows logic formulas to be added to the knowledgebase using standard Python syntax . For instance, suppose that a mapping fromusers to roles is given by the following Python data structure, consisting of a listof tuples, and that a list of access rights is given in a similar way:
InRole = [ (’John’, ’Student’), (’Ann’, ’Admin’) ] (1)
Allowed = [ (’Student’, ’PublicData’), (’Admin’, ’Passwords’) ] (2)Suppose we now want to verify that certain users indeed have access to certainresources, e.g.,
Access = [ (’Ann’, ’Passwords’)]. The following Python expres-sion then checks that Ann is indeed allowed to access the password data: all(any((u,r) in InRole and (r,res) in Allowed for r in Role) for (u,res) in Access)
Our API accepts the same Python expression, but allows it to be used in dif-ferent ways: for instance, if the programmer does not assign a value to
InRole herself (i.e., she omits statement (1)), then the IDP system will itself compute
Appendix G n assignment of users to roles that ensures that all of the required accesses arepossible (i.e., Ann will be placed in the role
Admin to ensure that she can accessthe password data). In this way, the flexibility of a declarative approach can beexperienced without any new syntax. We therefore believe that this API may bea useful tool to introduce programmers to the power of logic-based approaches.In many contexts, however, not programmers need to be convinced, but busi-ness people. Despite the significant technical differences between traditional soft-ware engineering and knowledge-based methods, business users may simply see achoice between either paying a programmer to deliver a piece of software or pay-ing a knowledge engineer to deliver a piece of software. Here, we believe that theunique selling proposition of knowledge-based methods is that they may allowto “eliminate the middle man”, by giving ownership of the domain knowledgeback to the business instead of to an IT departement.The recent Decision Model and Notation (DMN) standard published bythe Object Management Group has been developed specifically to allow domainexperts without any background in logic or computer science to construct aformal model of a decision process. Using this notation, a business expert coulddefine the decision logic for access control by the following three tables: C Input OutputUser Role“John” “Student”“Ann” “Admin”“Ann” “Student” C Input OutputRole Resource“Student” “PublicData”“Admin” “PublicData”“Admin” “Passwords” U Input OutputRole AccessGranted default: false
Request true
Here, the “C” in the top left of the first table represents the “Collect” hitpolicy, meaning that a user belongs to all of the roles that are mentioned for herin the table. The second table expresses that the user has access to all resourcesthat correspond to one of the roles to which she belongs. Finally, the third tableexpresses that when a user requests a resource to which she has access, the accessshould be granted, and otherwise it should not.The tabular notation is not only intuitive for business people, it also allowsthe completeness and correctness of the decision procedure to be easily checked.Currently, most reasoning systems for DMN have evolved from rule-based expertsystems and they typically only allow forward propagation. However, since aDMN model expresses a purely declarative piece of knowledge, there is no reasonwhy other inference tasks could not be applied to it, for instance, by translatingsuch a model to input for the IDP system, as done (currently still manually) in[2]. We suspect that the DMN language might easily be extendable to allow morecomplex kinds of knowledge to be expressed, while retaining the ease-of-use fordomain experts. In this way, more of the power of logic-based systems could beput directly at the finger tips of domain experts and business decision makens,eliminating the need for an intervening programmer or knowledge engineer. eferences
1. M. Bruynooghe, H. Blockeel, B. Bogaerts, B. De Cat, S. De Pooter, J. Jansen,A. Labarre, J. Ramon, M. Denecker, and S. Verwer. Predicate logic as a modelinglanguage: modeling and solving some machine learning and data mining problemswith IDP3.
Theory and Practice of Logic Programming , 15(6):783–817, 2015.2. I. Dasseville, L. Janssens, G. Janssens, J. Vanthienen, and M. Denecker. Com-bining dmn and the knowledge base paradigm for flexible decision enactment. In
Supplementary Proceedings of the RuleML 2016 Challenge . CEUR-WS. org, 2016.3. J. Vennekens. Lowering the learning curve for declarative programming: A pythonAPI for the IDP system. pages 86–102, 2016. asier Rules and Constraints for Programming ∗ Yanhong A. Liu Scott D. Stoller
We discuss how rules and constraints might be made easier for more conventional program-ming. We use a language that extends DistAlgo, which extends Python, and we use the RBACprogramming challenge plus distributed RBAC as examples.Python. Python is a high-level programming language with an easy-to-read syntax. It supportsconventional imperative programming and object-oriented programming. It also supports database-style programming with sets and queries (comprehension and generator expressions) and functionalprogramming with recursive functions and even a syntax for lambda. However, it does not supportrules and constraints.DistAlgo. DistAlgo [LSL17, LL17] is a language that extends Python to support distributedprogramming with processes and message passing. It also extends Python to support more powerfulqueries with constraints and tuple patterns, including logic quanti(cid:28)cations with witnesses. Thesequery constructs were created to better express high-level synchronization conditions over messagesand processes but also high-level queries in general, while integrating seamlessly with imperativeprogramming.For example, consider a set UR of user-role pairs and a particular user user . The set of roles that user has can be expressed using a set comprehension with a tuple pattern as follows. setof(r, (_user,r) in UR) The membership condition is exactly a constraint, and in general any number of constraints can beused. (_user,r) is a tuple pattern, where the underscore indicates a variable on the left side of amembership clause whose value is bound before the query. Note that we have also implemented amore ideal syntax for the same query, shown below, but here we use Python accepted syntax, shownabove, so that the Python parser can be used. {r: (=user,r) in UR}
Similarly one may compute aggregation (e.g., countof and minof ) over sets, and universal andexistential quanti(cid:28)cations ( each(x in s, has= p(x) or some(x in s, has= p(x)) .Extension with constraint optimization. With the more powerful set queries as above, it iseasy to write an additional constraint to (cid:28)lter out only those that minimize some objective function,e.g., the constraint f(r) == minof(f(x), (_user,x) in UR) can be inserted in the set comprehensionshown above. It is even easier to simply add the constraint as follows, minimize= exp where exp expresses the objective function, e.g., minimize= f(r) can be inserted in the set compre-hension shown above. This is just as in mathematical programming tools. ∗ Authors’ contact: Computer Science Department, Stony Brook University, Stony Brook, New York.Email: {liu,stoller}@cs.stonybrook.edu. This work was supported in part by NSF under grants CCF-1414078, IIS-1447549, and CNS-1421893, and ONR under grant N000141512208. Appendix H xtension with rules. Just as declaring a named function or method, one should be able toeasily declare a named set of rules, e.g., def rules (name=’Trans_rules’):if edge(x,y): path(x,y)if edge(x,z) and path(z,y): path(x,y) and call an inference function to infer values using the rule set, e.g., the following returns the set ofpairs for which predicate path holds using rule set Trans_rules given a set of edges RH . infer(path, edge=RH, rules=Trans_rules) One can also use path(1,v) in place of path to return the set of values of v for which path(1,v) holds.Note that predicates edge and path are simply set-valued variables, without needing high-order logic.Extension with backtracking under choices. While planning problems can be expressed asconstraint solving and optimization, it is more direct if actions in the program can be expressed withchoices, with actions sequenced, with backtracking in an allowed scope, until sequences of actionssatisfying a condition are found and returned or all choices are enumerated. This is easily expressedwith a pair of assume and achieve statements that surround statements with choices.In particular, given a set of actions acts that are allowed operations, e.g., method de(cid:28)nitions,let instances(acts) generate all instances of calls to those methods, and let do(a) execute methodcall a . The following code (cid:28)nds any sequence that satis(cid:28)es condition , where some makes a choice. assume(True)seq = []while not condition:if some(a in instances(acts)):do(a)seq.append(a)achieve(anyof(seq)) Also, a cost function can be computed along the sequence, and solutions that minimize the costmay be returned.Implementation. The extensions are being implemented by extending DistAlgo. The imple-mentation is currently incomplete. The main challenge will be e(cid:30)cient implementation to providecompetitive performance compared with lower-level or more complex manually programmed solu-tions.RBAC programming challenge solution. The Appendix shows how to express all componentsand functions of the RBAC programming challenge, plus a component for distributed RBAC, in theextended language. It is aimed to express everything in the clearest and most direct way possible. process in class header is needed only for distributed execution for the distributed RBAC com-ponent; for others, it is included only to allow use of more powerful set queries with constraintsand tuple patterns. pre for preconditions could be implemented simply as assert in Python but weplan to support it directly in the extensions to DistAlgo.These components can run with DistAlgo:
CoreRBAC , HierarchicalRBAC_set , HierarchicalRBAC , CoreRBACwithSSD , HierarchicalRBACwithSSD , and
DistRBAC . Their less powerful variants in Pythonwithout
DistRBAC were run and optimized to run e(cid:30)ciently previously [LWG +
06, GLSR12].These do not currently run:
HierarchicalRBAC_rules and
AdminRBAC .2 eferences [GLSR12] Michael Gorbovitski, Yanhong A. Liu, Scott D. Stoller, and Tom Rothamel. Composing trans-formations for instrumentation and optimization. In Proceedings of the ACM SIGPLAN 2012Workshop on Partial Evaluation and Program Manipulation, pages 53(cid:21)62, 2012.[LL17] Bo Lin and Yanhong A. Liu. DistAlgo: A language for distributed algorithms. http://github.com/DistAlgo, 2017. Beta release September 27, 2014, latest release November 23, 2017.[LSL17] Yanhong A. Liu, Scott D. Stoller, and Bo Lin. From clarity to e(cid:30)ciency for distributed algorithms.ACM Transactions on Programming Languages and Systems, 39(3):12:1(cid:21)12:41, May 2017.[LWG +
06] Yanhong A. Liu, Chen Wang, Michael Gorbovitski, Tom Rothamel, Yongxi Cheng, YingchaoZhao, and Jing Zhang. Core role-based access control: E(cid:30)cient implementations by transforma-tions. In Proceedings of the ACM SIGPLAN 2006 Workshop on Partial Evaluation and ProgramManipulation, pages 112(cid:21)120, 2006.
Appendix: RBAC challenge in a language that extends Python """ We consider Role - Based Access Control ( RBAC ) with 6 components : Core RBAC , Hierarchical RBAC , Core RBAC with Static Separation of Duty constraint ( also called Constrained RBAC ), Hierarchical RBAC with Static Separation of Duty constraint , Administrative RBAC , and Distributed RBAC """ class CoreRBAC ( process ): """ Core RBAC keeps several sets including the following :
USERS : set of users ROLES : set of roles PERMS : set of permissions UR: set of user - role pairs PR: set of permission - role pairs with constraints :
UR subset USERS * ROLES PR subset PERMS * ROLES update functions for each set , subject to the constraints above :
AddUser , DeleteUser , AddRole , DeleteRole , AddPerm , DeletePerm AddUR , DeleteUR , AddPR , DeletePR each Add has pre - conditions : the element is not yet in the set and the constraints will not be violated each Delete has the pre - condition that the element is in the set , and maintains the constraints query functions including the following : AssignedUsers ( role ): the set of users assigned to role in UR AssignedRoles ( user ): the set of roles assigned to user in UR UserPermissions ( user ): the set of permissions assigned to the roles assigned to user CheckAccess (user , perm ): whether some role is assigned to user and is granted perm """ def setup (): self . USERS = set () self . ROLES = set () self . PERMS = set () self .UR = set () self .PR = set () def AddUser ( user ): USERS . add ( user ) def DeleteUser ( user ): UR -= setof (( user ,r), r in ROLES ) USERS . remove ( user ) def AddRole ( role ): ROLES . add ( role ) def DeleteRole ( role ): UR -= setof ((u, role ), u in USERS ) PR -= setof ((p, role ), p in PERMS ) ROLES . remove ( role ) def AddPerm ( perm ): PERMS . add ( perm ) def DeletePerm ( perm ): PR -= setof (( perm ,r), r in ROLES ) PERMS . remove ( perm ) def AddUR (user , role ): UR. add (( user , role )) def DeleteUR (user , role ): UR. remove (( user , role )) def AddPR (perm , role ): PR. add (( perm , role )) def DeletePR (perm , role ): PR. remove (( perm , role )) def AssignedUsers ( role ): return setof (u, (u, _role ) in UR) def AssignedRoles ( user ): return setof (r, ( _user ,r) in UR) def UserPermissions ( user ): return setof (p, ( _user ,r) in UR , (p,r) in PR) def CheckAccess (user , perm ): return some (r in ROLES , has = (user ,r) in UR and (perm ,r) in PR) class HierarchicalRBAC_set ( CoreRBAC , process ): def Trans (E): T = E while some ((x,y) in T, (y,z) in E, has = (x,z) not in T):
T. add ((x,z)) return T | setof ((r,r), r in ROLES ) class HierarchicalRBAC_rules ( CoreRBAC , process ): def rules ( name = ’ Trans_rules ’): if edge (x,y): path (x,y) if edge (x,z) and path (z,y): path (x,y) def Trans (E): return infer (path , edge =E, rules = Trans_rules ) | setof ((r,r), r in ROLES ) class HierarchicalRBAC ( HierarchicalRBAC_set , process ): """
Hierarchical RBAC keeps also a role hierarchy :
RH: set of pairs of roles , called ascendant and descendant roles , where an ascendant role inherits permissions from a descendant role with constraints :
RH subset ROLES * ROLES , and RH is acyclic update functions for RH , subject to the constraints above :
AddInheritance (asc , desc )
DeleteInheritance (asc , desc ) with the same kinds of pre - conditions as updates in CoreRBAC query functions including the following :
Trans : the transitive closure of role hierarchy union reflexive role pairs
AuthorizedUsers ( role ): the set of users of role or ascendant roles of role
AuthorizedRoles ( user ): the set of roles of user or descendant roles of the roles """ def setup (): self .RH = set () def AddInheritance (a, d):
RH. add ((a,d)) def DeleteInheritance (a, d):
RH. remove ((a,d)) def AuthorizedUsers ( role ): return setof (u, (u, asc ) in UR , (asc , _role ) in Trans (RH )) def AuthorizedRoles ( user ): return setof (r, ( _user , asc ) in UR , (asc ,r) in Trans (RH )) class CoreRBACwithSSD ( CoreRBAC , process ): """
Core RBAC with SSD keeps also a set of SSD items , where each item has : a name , a set of roles , and a cardinality with constraints : all roles in all SSD items subset ROLES for each SSD item , its cardinality is > 0 and < the number of its roles for each user , for each SSD item , the number of assigned roles ( AssignedRoles ) of the user that are in the item ’s set of roles is at most the item ’s cardinality update functions , subject to the constraints above : CreateSsdSet (name , roles , c): add SSD item having name , roles , c
DeleteSsdSet ( name ): delete SSD item having name
AddSsdRoleMember (name , role ): add role to roles of SSD item having name
DeleteSsdRoleMember (name , role ): del role fr roles of SSD item having name
SetSsdSetCardinality (name , c): set c to be card . of SSD item having name with the same kinds of pre - conditions as updates in CoreRBAC , except that all updates have also pre - conditions that no constraints will be violated query functions including the following :
SsdRoleSets (): the set of names of SSD items
SsdRoleSetRoles ( name ): the set of roles in SSD item having name
SsdRoleSetCardinality ( name ): the cardinality of SSD item having name """ def setup (): self . SsdNAMES = set () self . SsdNR = set () self . SsdNC = set () def constraint ( name = ’SSD ’): return each (u in USERS , (name ,c) in SsdNC , has = countof (r, r in AssignedRoles (u), ( _name ,r) in SsdNR ) <= c) def CreateSsdSet (name , roles , c):
SsdNAMES . add ( name )
SsdNR |= setof (( name ,r), r in roles )
SsdNC . add (( name ,c)) def DeleteSsdSet ( name ):
SsdNR -= setof (( name ,r), r in SsdRoleSetRoles ( name ))
SsdNC . remove (( name , SsdRoleSetCardinality ( name )))
SsdNAMES . remove ( name ) def AddSsdRoleMember (name , role ):
SsdNR . add (( name , role )) def DeleteSsdRoleMember (name , role ):
SsdNR . remove (( name , role )) def SetSsdSetCardinality (name , c): SsdNC . remove (( name , SsdRoleSetCardinality ( name )))
SsdNC . add (( name ,c)) def SsdRoleSets (): return SsdNAMES def SsdRoleSetRoles ( name ): return setof (r, ( _name ,r) in SsdNR ) def SsdRoleSetCardinality ( name ): return anyof (c, ( _name ,c) in SsdNC ) class HierarchicalRBACwithSSD ( HierarchicalRBAC , CoreRBACwithSSD , process ): """
Hierarchical RBAC with SSD combines all from
Hierarchical RBAC and Core RBAC with SSD , except that the SSD constraint uses AuthorizedRoles in place of AssignedRoles . """ def constraint ( name = ’SSD ’): return each (u in USERS , (name ,c) in SsdNC , has = countof (r, r in AuthorizedRoles (u), ( _name ,r) in SsdNR ) <=c) class AdminRBAC ( HierarchicalRBACwithSSD ): """
Administrative RBAC for HierarchicalRBACwithSSD has optimization and planning functions :
MineMinRoles : find a smallest set of roles with UR ’ and PR ’ assignments such that UR ’ * PR ’ = UR * PR
MineMinRoleAssignments : find a smallest set of UR ’ and PR ’ assignments such that UR ’ * PR ’ = UR * PR = UP
GetRolesPlan (user , roles , acts ): find a sequence of actions , i.e., updates , in acts that allows user to get roles
GetRolesShortestPlan (user , roles , acts ): find a shortest sequence of actions , i.e., updates , in acts that allows user to get roles
Any subset of updates can be used as acts .
All constraints must hold after each action .
The first two can have a version that includes finding RH ’.
Administrative RBAC could also be for
CoreRBAC , HierarchicalRBAC , or CoreRBACwithSSD . """ def MineMinRoles (): return anyof ((R, UR2 , PR2 ), R in subset ( ran (UR )& ran (PR )) ,
UR2 in subset ( dom (UR )*R), PR2 in subset ( dom (PR )*R),
UR2 * PR2 == UR * PR , minimize = count (R)) def MineMinRoleAssignments (): return anyof ((R, UR2 , PR2 ), R in subset ( ran (UR )& ran (PR )) ,
UR2 in subset ( dom (UR )*R), PR2 in subset ( dom (PR )*R),
UR2 * PR2 == UR * PR , minimize = count ( UR2 + PR2 )) def GetRolesPlan (user , roles , acts ): assume ( True ) seq = [] while not each (r in roles , has = ( _user ,r) in UR ): if some (a in instances ( acts )): do(a) seq . append (a) achieve ( anyof ( seq )) def GetRolesShortestPlan (user , roles , acts ): assume ( True ) seq = [] cost = 0 while not each (r in roles , has = ( _user ,r) in UR ): if some (a in instances ( acts )): do(a) seq . append (a) cost += 1 achieve ( anyof (( seq , cost ), minimize = cost )) class DistRBAC ( HierarchicalRBACwithSSD , process ): """ A Distributed RBAC process keeps also the following sets :
OTHERS : set of other RBAC processes
GuestR : set of pairs of a rbac - role pair and a guest role with constraints : domain ( domain ( GuestR )) subset OTHERS range ( GuestR ) subset ROLES update functions for each set subject to the constraints above :
AddGuestRole , DeleteGuestRole
AssignGuestRole : assign to user of role in rbac the corresponding guest roles
DeassignGuestRole deassign from user of role in rbac the corresponding guest roles query functions :
GuestRoles (rbac , role ): the set of guest roles for role of rbac
OthersRoles ( guest ): the set of rbac - role pairs for role guest
Distributed RBAC can also be for only
CoreRBAC , HierarchicalRBAC , or CoreRBACwithSSD , or Administrative RBAC for any of these . """ def setup ( OTHERS ): self . GuestR = set () def AddGuestRole (rbac , role , guest ):
GuestR . add ((( rbac , role ), guest )) def DeleteGuestRole (rbac , role , guest ):
GuestR . remove ((( rbac , role ), guest )) def GuestRoles (rbac , role ): return setof ( guest , (( _rbac , _role ), guest ) in GuestR ) def OthersRoles ( guest ): return setof (( rbac , role ), (( rbac , role ), _guest ) in GuestR ) def AddGuestUR (user , rbac , role ): send (( ’ credential ’, user , role ), to= rbac ) if await ( received (( ’accept ’, user , role ), from_ = rbac )): for r in GuestRoles (rbac , role ): AddUR (user , r) def DeleteGuestUR (user , rbac , role ): for r in GuestRoles (rbac , role ):
DeleteUR (user , r) def receive ( msg =( ’ credential ’, user , role ), from_ = rbac ): if (user , role ) in UR: send (( ’accept ’, user , role ), to= rbac ) else : send (( ’reject ’, user , role ), to= rbac ) def receive ( msg =( ’ AddGuestUR ’, user , rbac , role )):
AddGuestUR (user , rbac , role ) def receive ( msg =( ’ DeleteGuestUR ’, user , rbac , role )):
DeleteGuestUR (user , rbac , role ) ecurity Policies in Constraint Handling Rules Position Paper
Thom Fr¨uhwirthUlm University, Germany
Abstract
Role-Based Access Control (RBAC) is a popular security policy frame-work. User access to resources is controlled by roles and privileges. Con-straint Handling Rules (CHR) is a rule-based constraint logic language.CHR has been used to implement security policies for trust managementsystems like RBAC for more than two decades.
Constraint Handling Rules (CHR) [Fr¨u09, Fr¨u18, Fr¨u15, FR18] is a logicalrule-based language and framework employing constraints. In this short paper,we describe work on RBAC that is implemented in CHR. We just cite the mainworks for each group of authors. Further references may be found in the citedpapers and/or by googling.Based on [BFM02], Bistarelli et. al. [BMS10, BMS12] apply an extension ofDatalog by weighted facts to model role-based trust management. Deductioncan validate access requests. Abduction can compute missing credentials if theaccess is denied and it can compute the level of preference that would grantthe access. Both deduction and abduction are expressed in Weighted Datalogand translated into CHR for execution. [BCMS14] show how this deductive andabductive reasoning can be efficiently ported to Android enabling distributedauthorization. Both deduction and abduction are implemented as programs ina version of CHR that is embedded into Java (JCHR).Ribeiro et. al. [RG99] present a static analyzer that automatically verifiesconsistency of workflow specifications written in WPDL (Workflow Process Def-inition Language) and of specifications in a security policy language (SPL). Theanalyzer is implemented with CHR embedded in SICstus Prolog. [RZFG00]further describes this Policy Consistency Verifier (PVC). It now includes con-straints automatically annotated with temporal information. [RF07] presentsfurther work on the security policy language (SPL). It can express the conceptsof permission and prohibition, and some restricted forms of obligation as well ashistory-based approaches. Given a SPL specification, it is verified using CHRand then compiled to Java into a corresponding security access monitor. Thecurrent CHR verifier has about 300 rules and is able to solve all SPL constraints,including the constraints implicitly qualified with time.1
Appendix I he Object Constraint Language (OCL) is a declarative text language de-scribing rules applying to Unified Modeling Language (UML) models. OCLprovides constraint and object query expressions on models that cannot be ex-pressed by diagrammatic notation. OCL is now a key component of the newOMG standard recommendation for transforming models. Model finders au-tomatically verify UML/OCL models by checking satisfiability (consistency)of models using example instances. The work of [DTVH16] presents oclCHR https://uet.vnu.edu.vn/~hanhdd/oclCHR/ , a verifier implemented in CHRembedded in Eclipse Prolog. It is of interest here, because the authors use anUML model of RBAC as their main example.Finally, we would like to cite two approaches of RBAC in logical languagesthat can be readily translated into CHR. [BS03] show how a range of role-basedaccess control (RBAC) models may be usefully represented as executable logicalspecifications in constraint logic programs (CLP). Like Weighted Datalog, CLPclauses can be translated to CHR [Fr¨u09].[OPR18] presents a declarative interpretation of Access Permissions (APs)as Linear Concurrent Constraint Programs (LCC). By interpreting LCC pro-grams as formulae in intuitionistic linear logic, they can verify properties ofAP programs such as deadlock detection, correctness, and concurrency. CHRalso admits a linear logic interpretation [Bet14] and is closely related to themore recent LCC language. Translations between LCC and CHR are given in[Mar10].Concluding, CHR is a often used language to build reasoning services. Inthis paper, we showed this surveying shortly work on the problem of securitypolicies, i.e. access control. We would like to thank the anonymous referees fortheir helpful comments. References [BCMS14] Stefano Bistarelli, Gianpiero Costantino, Fabio Martinelli, andFrancesco Santini. An improved role-based access to android appli-cations with jchr. In
Availability, Reliability and Security (ARES),2014 Ninth International Conference on , pages 341–348. IEEE, 2014.[Bet14] Hariolf Betz.
A unified analytical foundation for constraint handlingrules . BoD, 2014.[BFM02] Stefano Bistarelli, Thom Fr¨uhwirth, and Michael Marte. Soft con-straint propagation and solving in chrs. In
Proceedings of the 2002ACM symposium on Applied computing , pages 1–5. ACM, 2002.[BMS10] Stefano Bistarelli, Fabio Martinelli, and Francesco Santini. A for-mal framework for trust policy negotiation in autonomic systems:Abduction with soft constraints. In
International Conference onAutonomic and Trusted Computing , pages 268–282. Springer, 2010.2 BMS12] Stefano Bistarelli, Fabio Martinelli, and Francesco Santini. Asemiring-based framework for the deduction/abduction reasoning inaccess control with weighted credentials.
Computers & Mathematicswith Applications , 64(4):447–462, 2012.[BS03] Steve Barker and Peter J Stuckey. Flexible access control policyspecification with constraint logic programming.
ACM Transactionson Information and System Security (TISSEC) , 6(4):501–546, 2003.[DTVH16] Duc-Hanh Dang, Anh-Hoang Truong, and Dang Van Hung. Onmodel finding with constraint patterns. In
SoMeT , pages 279–290,2016.[FR18] Thom Fr¨uhwirth and Frank Raiser.
Constraint Handling Rules-Compilation, Execution, and Analysis: Large Print Edition . BoD,2018.[Fr¨u09] Thom Fr¨uhwirth.
Constraint handling rules . Cambridge UniversityPress, 2009.[Fr¨u15] Thom Fr¨uhwirth. Constraint handling rules – what else? In
Inter-national Symposium on Rules and Rule Markup Languages for theSemantic Web , pages 13–34. Springer, 2015.[Fr¨u18] Thom Fr¨uhwirth.
The CHR Web Site – . Ulm University, 2018.[Mar10] Thierry Martinez. Semantics-preserving translations between linearconcurrent constraint programming and constraint handling rules.In
Proceedings of the 12th international ACM SIGPLAN symposiumon Principles and practice of declarative programming , pages 57–66.ACM, 2010.[OPR18] Carlos Olarte, Elaine Pimentel, and Camilo Rueda. A concurrentconstraint programming interpretation of access permissions.
Theoryand Practice of Logic Programming , pages 1–44, 2018.[RF07] Carlos Ribeiro and Paulo Ferreira. A policy-oriented language forexpressing security specifications.
IJ Network Security , 5(3):299–316, 2007.[RG99] Carlos Ribeiro and Paulo Guedes. Verifying workflow processesagainst organization security policies. In
Enabling Technologies:Infrastructure for Collaborative Enterprises, 1999.(WET ICE’99)Proceedings. IEEE 8th International Workshops on , pages 190–191.IEEE, 1999.[RZFG00] Carlos Ribeiro, Andr´e Z´uquete, Paulo Ferreira, and Paulo Guedes.Security policy consistency. In T. Fruehwirth et al., editors,
RCoRP’00: Proc. 1st Workshop on Rule-Based Constraint Reasoning andProgramming , 2000. arXiv preprint cs/0006045.3 ow to upgrade ASPfor true dynamic modelling and solving? Torsten Schaub ∗ Inria, Rennes, France and University of Potsdam, Germany [email protected]
The world is dynamic, and ASP is not!
This is a provocative way to say thatASP is not up to dealing with many complex real-world applications havinga dynamic nature, let alone transitions over states, not even mentioning morefine-grained temporal structures.Although ASP has already been applied in various domains in academiaand industry with remarkable success [8, 9], a closer look reveals that thisconcerns mostly static or smaller dynamic domains. For example, ASP ishighly competitive in static domains such as timetabling [2] and workforcemanagement [19], whereas it lags behind when it comes to substantial dynamicones, as for instance robotic intra-logistics as discussed below. In fact, there isstill quite a chasm between its level of development for addressing static anddynamic domains. This is because its modeling language as well as its groundingand solving machinery aims almost exclusively at handling static knowledge,while dynamic knowledge is usually indirectly dealt with via reductions to thestatic case.In order to overcome this barrier and to upgrade ASP to the next level,dealing with complex dynamic problems, three areas appear to be relevant tome. The most popular languages for modeling dynamic systems in the realm of ASPare temporal extensions of Equilibrium Logic [1], the host logic of ASP, and actionlanguages [14]. Although both constitute the main directions of non-monotonictemporal systems, their prevalence lags way behind the usage of plain ASP for ∗ Torsten Schaub has been supported by the German Science Foundation (DFG): projectsSCHA 550/9 and 11. This personal view comes with a lot of self references — sorry for that! Appendix J odeling dynamic domains. Hence, notwithstanding the meticulous modeling ofdynamics in ASP due to an explicit representation of time points, it seems thatits pragmatic advantages, such as its rich (static) modeling language and readilyavailable solvers, often seem to outweigh the firm logical foundations of bothdedicated approaches. Although the true reasons are arguably inscrutable, letus discuss some possible causes.The appeal of action languages lies in their elegant syntactic and semanticsimplicity: they usually consist of static and dynamic laws inducing a uniquetransition system. Although most of them are implemented in ASP, theirsimplicity denies the expressive modeling possibilities of ASP. Also, despite somerecent reconciliation [16], existing action languages lack the universality of ASPas reflected by the variety of variants.Temporal Equilibrium Logic (TEL; [1]) builds upon an extension of the logicof Here-and-There [15] with Linear Temporal Logic (LTL; [18]). This results inan expressive non-monotonic modal logic, which relies upon the general syntaxof LTL and possesses a computational complexity beyond LTL [3]. As in LTL,a model in TEL is an infinite sequence of states, called a trace. This rulesout computation by ASP technology (and necessitates model checking) and issomewhat unnatural for applications like planning, where plans amount to finiteprefixes of one or more (infinite) traces.One proposal to overcome these issues is to restrict TEL to finite traces,similar to the restriction of LTL to LTL f advocated in [5]. This is detailed in [4]and accompanied with an extension of the ASP system clingo , dubbed telingo and available at https://github.com/potassco/telingo . telingo extends thefull-fledged input language of clingo with temporal operators and computestemporal models incrementally by multi-shot solving [11]. The need for dedicated encoding and solving techniques for handling dynamicdomains stems from the necessity to implement fluents, that is, propositionschanging their value over time. In ASP, just as other constraint-based approacheslike CP or SAT, this amounts to creating a copy of each fluent and related rulesper time point. The reduction of the resulting redundancy is the primary targetof the aforementioned dedicated reasoning techniques.First of all, we should realize that modeling and encoding a dynamic domainmay amount to quite different specifications, both being declarative but aimingat different conceptions at distinct levels of the domain. The easiest way torealize the difference between modeling and encoding is to consider a temporalrule a ( X ) ← • b ( X ) in which ‘ • ’ denotes the “previous” operator, or in telingo syntax: a(X) :- ’b(X) , that is finally encoded as a(X,t) :- b(X,t-1) where Another good example for this are (arithmetic) CSPs, nicely modeled by expressions like x + y < x ≤ , x ≤ , . . . (rather than a direct encoding usingequalities x = 1 , x = 2 , . . . ). he parameter ‘ t ’ is handled by multi-shot solving [11]. Obviously, modeling isideally more abstract than encoding by dropping aspects like the implementationof time by increasing integers. Also, the targeted implementation using parame-ters ‘ t ’ (instead of variables ‘ T ’) remains hidden. But apart from this abstraction,no real gain is obtained as regards the elimination of redundancy. Unlike this,multi-shot solving cuts back redundancies by avoiding repeated grounding andsolving efforts.Much more is possible. Encoding-wise an exemplar is the parallel representa-tion of sequential plans which has been investigated in SAT planning [7, 21]. Afirst attempt to transfer this to ASP is given in [6]. Another example is multi-path planning in logistics warehouses, where a two-step abstraction encodingtechnique was used [17] to scale up to state of the art algorithms. Certainly,many more such principled techniques exist but are no matter of common knowl-edge. Solving-wise, the semantic links between the aforementioned fluent copiesneed to be exploited. Again, SAT planning serves us as an exemplar, whereheuristics were used in [20] to provide such links. This idea has led to theheuristic directives in clingo [12]. Another solving technique was put forwardin [10], where ground multi-state invariants are extracted and generalized inorder to be fed back into the solving process, thus extending their scope to allsimilar state combinations. And much more can and needs to be done!
The upgrade of ASP is moreover threatened by a lack of complex benchmarkscenarios mimicking the needs of dynamic real-world applications. In contrastto many available benchmark suites, often supplied by automatic instancegenerators, real-world applications are rarely disseminated, either because theyare classified or come only with a handful of instances. Another commonalityof existing benchmark suites is that they are kept simple, stick to basic ASP,and usually feature at most a single specifics, so that they can be processedby as many systems as possible. However, this is in contrast to many real-world applications whose solution requires the integration of multiple types ofknowledge and forms of reasoning. Last but not least, a feature distinguishingASP from all other solving paradigms is its versatility, which is best put inperspective by solving multi-faceted problems.The fear is thus that the lack of complex benchmark scenarios becomes amajor bottleneck in ASP’s progression towards real-world applications, and hencethat more and more should be made available to our community. As a first stepto overcome this problem, we propose in [13] the domain of robotic intra-logistics ,a key domain in the context of the fourth industrial revolution, as witnessedby Amazon’s Kiva, GreyOrange’s Butler, and Swisslog’s CarryPick systems. This is implemented in the plasp system available at https://github.com/potassco/plasp . This is implemented in the ginkgo system available at https://github.com/potassco/ginkgo . , , ll of them aim at automatizing warehouse operations by using robot vehiclesthat drive underneath mobile shelves and deliver them to picking stations. Fromthere, workers pick and place the requested items in shipping boxes. Apartfrom the great significance of this real-world domain, our choice is motivated byseveral aspects. First of all, the domain is highly dynamic. At the same time,the warehouse layout is grid-based and thus provides a suitable abstraction formodeling robot movements in ASP. Moreover, the domain offers a great variety ofmanifold problem scenarios that can be put together in an increasingly complexway. For instance, one may start with single or multi-robot path-finding scenariosinduced by a set of orders that are accomplished by using robots for transportingshelves to picking stations. This can be extended in various ways, for example, byadding shelf handling and delivery actions, considering order lines with multipleproduct items, keeping track of the number of ordered and/or stored productitems, modeling energy consumption and charging actions, taking into accountorder frequencies, supplies, and priorities, striving for effective layouts featuringdedicated locations, like highways or storage areas, and so on. Finally, the domainis extremely well-suited for producing scalable benchmarks by varying layouts,robots, shelves, orders, product items, etc. Inspired by this, we have developedthe benchmark environment asprilo [13] consisting of four parts (i) a benchmarkgenerator, (ii) a solution checker, (iii) a benchmark and solution visualizer, and(iv) a variety of reference encodings. The design of asprilo was driven by thedesire to create an easily configurable and extensible framework that allowsfor generating scalable, standardized benchmark suites that can be visualizedwith and without a corresponding solution. Correctness can be established viaa modular solution checker. The accompanying reference encodings may serveas exemplary bases for extended encodings addressing more complex scenarios.The asprilo framework is freely available at https://potassco.org/asprilo . Many people well beyond our community get interested by the modeling andsolving capabilities of ASP, its elegance, succinctness, transparency, and lastbut not least its effectiveness. We attract them by showcasing our exemplaryproblems and solutions. But at the end of the day, if we want to keep theminterested in ASP, we have to solve their problems.
Acknowledgments
I am grateful to Martin Gebser, Roland Kaminski, andthe four reviewers for their constructive comments ! As well, I would like tomention that many aspects arose in very fruitful collaborations with MutsunoriBanbara, Pedro Cabalar, Vladimir Lifschitz, Orkunt Sabuncu, and Tran CanSon, not to mention the terrific Potassco people! Thank you all!! carrypick eferences [1] F. Aguado, P. Cabalar, M. Di´eguez, G. P´erez, and C. Vidal. Temporalequilibrium logic: a survey. Journal of Applied Non-Classical Logics , 23(1-2):2–24, 2013.[2] M. Banbara, K. Inoue, B. Kaufmann, T. Okimoto, T. Schaub, T. Soh,N. Tamura, and P. Wanko. teaspoon: Solving the curriculum-based coursetimetabling problems with answer set programming.
Annals of OperationsResearch , 2018. To appear.[3] L. Bozzelli and D. Pearce. On the complexity of temporal equilibrium logic.In
Proceedings of the Thirtieth Annual Symposium on Logic in ComputerScience (LICS’15) , pages 645–656. IEEE Computer Society Press, 2015.[4] P. Cabalar, R. Kaminski, T. Schaub, and A. Schuhmann. Temporal answerset programming on finite traces.
Theory and Practice of Logic Programming ,2018. To appear.[5] G. De Giacomo and M. Vardi. Linear temporal logic and linear dynamiclogic on finite traces. In Rossi [22], pages 854–860.[6] Y. Dimopoulos, M. Gebser, P. L¨uhne, J. Romero, and T. Schaub. plasp3: Towards effective ASP planning. In M. Balduccini and T. Janhunen,editors,
Proceedings of the Fourteenth International Conference on LogicProgramming and Nonmonotonic Reasoning (LPNMR’17) , volume 10377of
Lecture Notes in Artificial Intelligence , pages 286–300. Springer-Verlag,2017.[7] Y. Dimopoulos, B. Nebel, and J. K¨ohler. Encoding planning problems innonmonotonic logic programs. In S. Steel and R. Alami, editors,
Proceedingsof the Fourth European Conference on Planning , volume 1348 of
LectureNotes in Artificial Intelligence , pages 169–181. Springer-Verlag, 1997.[8] E. Erdem, M. Gelfond, and N. Leone. Applications of ASP.
AI Magazine ,37(3):53–68, 2016.[9] A. Falkner, G. Friedrich, K. Schekotihin, R. Taupe, and E. Teppan. Indus-trial applications of answer set programming.
K¨unstliche Intelligenz , 2018.To appear.[10] M. Gebser, R. Kaminski, B. Kaufmann, P. L¨uhne, J. Romero, and T. Schaub.Answer set solving with generalized learned constraints. In M. Carro andA. King, editors,
Technical Communications of the Thirty-second Inter-national Conference on Logic Programming (ICLP’16) , volume 52, pages9:1–9:15. Open Access Series in Informatics (OASIcs), 2016.[11] M. Gebser, R. Kaminski, B. Kaufmann, and T. Schaub. Multi-shot ASPsolving with clingo.
Theory and Practice of Logic Programming , 2018. Toappear. 5
12] M. Gebser, B. Kaufmann, R. Otero, J. Romero, T. Schaub, and P. Wanko.Domain-specific heuristics in answer set programming. In M. desJardins andM. Littman, editors,
Proceedings of the Twenty-Seventh National Conferenceon Artificial Intelligence (AAAI’13) , pages 350–356. AAAI Press, 2013.[13] M. Gebser, P. Obermeier, T. Otto, T. Schaub, O. Sabuncu, V. Nguyen, andT. Son. Experimenting with robotic intra-logistics domains.
Theory andPractice of Logic Programming , 2018. To appear.[14] M. Gelfond and V. Lifschitz. Action languages.
Electronic Transactions onArtificial Intelligence , 3(6):193–210, 1998.[15] A. Heyting. Die formalen Regeln der intuitionistischen Logik. In
Sitzungs-berichte der Preussischen Akademie der Wissenschaften , page 42–56.Deutsche Akademie der Wissenschaften zu Berlin, 1930. Reprint inLogik-Texte: Kommentierte Auswahl zur Geschichte der Modernen Logik,Akademie-Verlag, 1986.[16] J. Lee, V. Lifschitz, and F. Yang. Action language BC: Preliminary report.In Rossi [22], pages 983–989.[17] V. Nguyen, P. Obermeier, T. Son, T. Schaub, and W. Yeoh. Generalized tar-get assignment and path finding using answer set programming. In C. Sierra,editor,
Proceedings of the Twenty-sixth International Joint Conference onArtificial Intelligence (IJCAI’17) , pages 1216–1223. IJCAI/AAAI Press,2017.[18] A. Pnueli. The temporal logic of programs. In
Proceedings of the Eight-teenth Symposium on Foundations of Computer Science (FOCS’77) , pages46–57. IEEE Computer Society Press, 1977.[19] F. Ricca, G. Grasso, M. Alviano, M. Manna, V. Lio, S. Iiritano, andN. Leone. Team-building with answer set programming in the gioia-tauroseaport.
Theory and Practice of Logic Programming , 12(3):361–381, 2012.[20] J. Rintanen. Planning as satisfiability: heuristics.
Artificial Intelligence ,193:45–86, 2012.[21] J. Rintanen, K. Heljanko, and I. Niemel¨a. Planning as satisfiability: parallelplans and algorithms for plan search.
Artificial Intelligence , 170(12-13):1031–1080, 2006.[22] F. Rossi, editor.
Proceedings of the Twenty-third International Joint Con-ference on Artificial Intelligence (IJCAI’13) . IJCAI/AAAI Press, 2013.[23] N. Tamura, A. Taga, S. Kitagawa, and M. Banbara. Compiling finite linearCSP into SAT.
Constraints , 14(2):254–272, 2009.6 Picat-based XCSP Solver – from Parsing,Modeling, to SAT Encoding
Neng-Fa Zhou and H˚akan Kjellerstrand CUNY Brooklyn College & Graduate Center hakank.org Abstract.
This short paper gives an overview of a Picat-based XCSP3solver, named PicatSAT, submitted to the 2018 XCSP competition. Thesolver demonstrates the strengths of Picat, a logic-based language, inparsing, modeling, and encoding constraints into SAT.
XCSP3
XCSP3 [1] is an XML-based domain specific language for describing constraintsatisfaction and optimization problems (CSP). XCSP3 is positioned as an in-termediate language for CSPs. It does not provide high-level constructs as seenin modeling languages. However, XCSP3 is significantly more complex than acanonical-form language, like FlatZinc. A constraint can sometimes be describedin either the standard format or simplified format. The advanced format, whichis used by group and matrix constraints, allows more compact description ofconstraints.
Picat
Picat [6] is a simple, and yet powerful, logic-based multi-paradigm programminglanguage. Picat is a Prolog-like rule-based language, in which predicates, func-tions, and actors are defined with pattern-matching rules. Picat incorporatesmany declarative language features for better productivity of software devel-opment, including explicit non-determinism, explicit unification, functions, listcomprehensions, constraints, and tabling. Picat also provides imperative lan-guage constructs, such as assignments and loops, for programming everydaythings. Picat provides facilities for solving combinatorial search problems, in-cluding a common interface with CP, SAT, and MIP solvers, tabling for dynamicprogramming, and a module for planning. PicatSAT uses the SAT module, whichgenerally performs better than the CP and MIP modules on competition bench-marks.
Parsing
The availability of different formats in XCSP3 makes it a challenge to parse theXCSP3 language. A parser implemented in C++ by the XCSP designers has
Appendix K ore than 10,000 lines of code. The entire Picat implementation of XCSP3 hasabout 2,000 lines of code, two-thirds of which is devoted to parsing and syntax-directed translation. As illustrated in the following example, Picat is well suitedto parsing. % E -> T E’ex(Si,So) => term(Si,S1), ex_prime(S1,So).% E’ -> + T E’ | - T E’ | eex_prime([’+’|Si],So) =>term(Si,S1),ex_prime(S1,So).ex_prime([’-’|Si],So) =>term(Si,S1),ex_prime(S1,So).ex_prime(Si,So) => So = Si. The parser follows the framework for translating context-free grammar into Pro-log [3]: a non-terminal is encoded as a predicate that takes an input string ( Si )and an output string ( So ), and when the predicate succeeds, the difference Si - So constitutes a string that matches the nonterminal. Unlike in Prolog, pattern-matching rules in Picat are fully indexed, which facilitates selecting right rulesbased on look-ahead tokens. Modeling
It is well known that loops and list comprehensions are a necessity for modelingCSPs. The following Picat example illustrates the convenience of these languageconstructs for modeling. post_constr(allDifferentMatrix(Matrix)) =>NRows = len(Matrix),NCols = len(Matrix[1]),foreach (I in 1..NRows)all_different(Matrix[I])end,foreach (J in 1..NCols)all_different([Matrix[I,J] : I in 1..NRows])end.
The allDifferentMatrix(Matrix) constraint takes a matrix that is representedas a two-dimensional array, and posts an all different constraint for each rowand each column of the matrix.
SAT Encoding
PicatSAT adopts the log encoding for domain variables. While log encoding hadbeen perceived to be unsuited to arithmetic constraints due to its hindrance2 o propagation [2], we have shown that log encoding can be made competitivewith optimizations [4]. There are hundreds of optimizations implemented in Pi-catSAT, and they are described easily as pattern-matching rules in Picat. Wehave also shown that, with specialization, the binary adder encoding is not onlycompact, but also generally more efficient than BDD encodings for PB con-straints [5]. PicatSAT adopts specialized decomposition algorithms for some ofthe global constraints. While competitive overall, PicatSAT is not competitivewith state-of-the-art CP solvers on benchmarks that use path-finding constraintsthat require reachability checking during search. The future work is to designefficient encodings for these global constraints. References
1. Frederic Boussemart, Christophe Lecoutre, and Gilles Audemard. XCSP3 - anintegrated format for benchmarking combinatorial constrained problems. Technicalreport, xcsp.org.2. Donald Knuth.
The Art of Computer Programming, Volume 4, Fascicle 6: Satisfi-ability . Addison-Wesley, 2015.3. Fernando C. N. Pereira and David H. D. Warren. Definite clause grammars forlanguage analysis - A survey of the formalism and a comparison with augmentedtransition networks.
Artif. Intell. , 13(3):231–278, 1980.4. Neng-Fa Zhou and H˚akan Kjellerstrand. Optimizing SAT encodings for arithmeticconstraints. In CP , pages 671–686, 2017.5. Neng-Fa Zhou and H˚akan Kjellerstrand. Encoding pb constraints into sat via binaryadders and bdds – revisited. In Workshop on Experimental Evaluation of Algorithmsfor Solving Problems with Combinatorial Explosion RCRA , 2018.6. Neng-Fa Zhou, H˚akan Kjellerstrand, and Jonathan Fruhman.
Constraint Solvingand Planning with Picat . Springer, 2015. software system should be declarativeexcept where it interacts with the real world Peter Van Roy ∗ Universit´e catholique de LouvainMay 30, 2018
Abstract
We propose a system design principle that explains howto use declarative programming (logic and functional)together with imperative programming. The advantagesof declarative programming are well known; they in-clude ease of analysis, verification, testing, optimiza-tion, maintenance, upgrading, and distributed imple-mentation. We do not elaborate on the advantages here,but rather focus on what part of the software systemshould be written declaratively. We observe that declar-ative programming cannot interact directly with the realworld while remaining declarative, since it does not sup-port common real-world concepts such as physical timeand named state. It is important to distinguish reason-ing about the real world from interacting with the realworld: declarative programming can do the first but notthe second. Other programming paradigms that sup-port these concepts must be used, such as imperativeprogramming (which contains named state). To opti-mize the system design, we propose that real-world con-cepts should only be used where they cannot be avoided,namely where the system interfaces with the real world.It follows that a software system should be built com-pletely declaratively except possibly where it interfaceswith the real world. We motivate this principle withexamples from our research and we outline a formal ar-gument to justify it.
The interplay between declarative (e.g., pure functionalor logic) programming and imperative programming(which uses named mutable state) has long been a sub-ject of debate in software design. Important questionsare which paradigm to use and when to use it; and whenand how to use the paradigms together. The book [1]presents these paradigms in a uniform framework, eachwith its kernel language, and carefully explains whateach can and cannot do. This shows that there is noone paradigm that is uniformly better than the others.Large programs will typically use different paradigms in ∗ This work is partially funded by the LightKone project inthe European Union Horizon 2020 Framework Programme undergrant agreement 732505. different parts, just as building a house requires multipleskills such as masonry, carpentry, plumbing, and elec-tricity. But determining which paradigm to use whereis left unanswered. This position paper gives a designprinciple that answers this question:A software system should be built completelywith declarative programming except where itinteracts with the real world.Section 2 gives two examples to motivate this principle.Section 3 defines what we mean by interaction with thereal world and gives a formal argument to support theprinciple. Section 4 discusses some ramifications of theprinciple, and Section 5 presents a brief conclusion.
Consider a client/server application in its simplest form:two clients communicating with one server. Each clientsends requests to the server and receives replies. Tosatisfy liveness of each client, the server must accepteach incoming request and reply to it within a reasonabledelay. The server’s handling of a client request shouldnot be impeded because of what the other client doesor does not do. The order of the server’s handling ofrequests cannot be determined in advance, because itdepends on the precise timing of the requests.
We give a more substantial example taken from our re-search into synchronization-free programming for dis-tributed systems, namely the Lasp programming sys-tem [2]. A Lasp program consists of a dataflow graphconnecting data structures with functional and logicaloperations (similar to SQL operations). The data struc-tures and operations are both designed to do convergentcomputation : each computation step adds informationmonotonically. In fact, the data structures are CRDTs(Conflict-free Replicated Data Type) [3]. To the pro-grammer, Lasp executes as a functional/logic programwith a dataflow semantics, similar to the deterministicdataflow of Chapter 4 in [1].1
Appendix L he data structures are replicated and information isperiodically disseminated between replicas. CRDTs aredesigned so that the replicas are always converging tothe correct result. This is extremely resilient. Changingthe timing of the dissemination messages has no effecton correctness. Dropped, delayed, or reordered mes-sages have no effect on correctness. The only possibleeffect is to slow down convergence. Node crashes havetwo possible results: either the crash has no effect ex-cept for slowing down convergence, or some informationdisappears completely.Lasp provides a functional semantics with a highlyresilient distributed implementation based on weak syn-chronization. A Lasp program needs stronger synchro-nization than periodic dissemination only when talkingto external clients (i.e., real-world interaction). We have given two examples that show the principle inaction. We now outline a formal argument to justifythe principle and to define it precisely. For brevity, weuse the lambda calculus, but any other declarative ex-ecution model that performs deduction from an initialinput could be used instead.
Consider the lambda calculus with a concurrent evalu-ation strategy. Given an initial lambda expression, wecan reduce it to its normal form. Any reduction orderwill lead to the same normal form, which is known asthe Church-Rosser property. The reduction may takemany steps. At any step in the reduction, there may beseveral different positions in the lambda expression thatcan be reduced next. By adding a scheduler to deter-mine how to choose the position reduced at each step, wecan define a concurrent form of functional programmingvery similar to the deterministic dataflow model givenin Chapter 4 of [1]. In this form, we can define deter-ministic concurrent agents that communicate throughstreams, similar to Kahn networks [4].
Real-world interaction requires that the computationtake into account input coming from the real world. Ifthere are several inputs, they need to be handled in someorder. This order is not known in advance; it becomesknown during the reduction. We are led to a sequence ofinputs, arriving one by one during the reduction process.If all inputs would be known in advance, then theycould be considered part of the initial expression, andthe system would be purely declarative. However, a keyproperty of the real world is that they are not knownin advance. They arrive during the reduction processbecause reduction steps take nonzero time. The arrivalorder is determined by the precise timing with respect to the reduction process. The order can affect the result.For example, if the computation builds a list, the orderof its elements can depend on the timing. We concludethat the new concept that must be added to determin-istic dataflow to allow interaction with the real world is time .It may be that an expression is not reducible untilan input arrives, in which case we say the reduction issuspended. When the input arrives, a reduction stepbecomes possible. When this step is taken, we say thereduction synchronizes with the input. On the otherhand, the expression may be reducible at several po-sitions, and an arriving input creates another positionwhere a reduction is possible. In this case, the systemis active but can accept new input during execution.
We claim that the design principle holds generally when-ever a system interacts with the real world. The real-world property “time” can appear in different guisesto the system, e.g., as nondeterminism (see above), asphysical wall-clock time (hardware clock), or as partialfailure.Interaction with the real world happens not just atthe API, but everywhere that the real world has to betaken into account. For example, MapReduce handlesa straggler (slow node) by speculatively running a copyof its task on another node. Detecting the slowness of astraggler depends on time, which is an interaction withthe real world.
This position paper presents a software design princi-ple that is a result of the author’s study of the differ-ences between declarative and imperative programmingfor system building. We are working on a full paperwith a detailed formal justification of the principle andits application to synchronization-free programming.
References [1] Peter Van Roy and Seif Haridi.
Concepts, Techniques,and Models of Computer Programming . MIT Press, 2004.[2] Christopher Meiklejohn and Peter Van Roy. Lasp: ALanguage for Distributed, Coordination-Free Program-ming. 17th International Symposium on Principles andPractice of Declarative Programming (PPDP), Siena,Italy, July 2015.[3] Marc Shapiro, Nuno Pregui¸ca, Carlos Baquero, andMarek Zawirski.
Conflict-free Replicated Data Types . IN-RIA Research Report RR-7687, July 2011.[4] Gilles Kahn. The Semantics of a Simple Language forParallel Programming. IFIP Congress, pp. 471–475,1974.2