Keywords

1 Introduction

The Connected Mobility Lab (CML) has been developed within the scope of a public funded project (see [1]) to enable smart mobility applications by seamlessly exchanging data and analytics. The CML integrates the services from different stakeholders – such as mobility, financial and IT services – to provide comprehensive mobility solutions to its users. Figure 1 shows how the CML core services such as security, accounting, data management and identity management enable the integration of data and processes from different mobility providers (partners) to provide the CML mobility services. The CML mobile application (CML App) runs on mobility assistant devices such as smart phone and touch points as shown in Fig. 1; the users can access the CML App and use the comprehensive CML mobility solution.

Fig. 1.
figure 1

The Connected Mobility Lab (CML) solution [1]

Full size image

The users of CML can be private persons or employees of a company that has a service agreement with the CML. A user may wish to use different mobility services to complete one single journey. Each stakeholder enforces his own business processes on the customers (CML users) who use his services, therefore CML must integrate different stakeholders’ processes.

A process is a set of interrelated activities or tasks that must be carried out to accomplish a goal [3]. A business process is also called a workflow, but we use the two words as synonymous. A workflow must be executed as it is specified, and only using the available information it has, i.e., no one is able to change, add additional steps or skip steps, etc. and the workflow should not use any interface that he is not allowed do use. This property is called “process integrity”. During the execution of the workflow, the participants may exchange each other documents, information, see [4].

For instance, a user might use a carsharing service from his home to the main train station, then park the car in one of available the parking lots and take a train to reach the final destination. During the trip, the user must obey the rules and conditions specified by that particular mobility provider. The CML provides a global workflow for the trip that enforces each stakeholder’s processes that must be executed by the user in order to complete the journey.

The CML users execute the workflow to consume the services offered by the CML. When users execute any task that involve accessing a service it is important to enforce strict access control. We enforce a least privilege principle for task authorizations within each workflow. The least privilege principle is a security concept where every computer module (such as a process, user, or program, depending on the subject) may be able to access only the information and resources that are necessary for its legitimate purpose. As a particular case, the principle “Need to Know” is a confidentiality policy which states that no subject should be able to read objects unless reading them is necessary for that subject to perform its functions [3]. What we need is a similar policy, but regarding integrity. We might call this principle “Need to Access”: it states that no subject should be able to write or change objects unless it is necessary to complete the required task of a process or workflow at that particular state. By enforcing the need to access principle, an entity can get privileges to execute a task only at the required step of the workflow. This provides workflow driven (wokflow-aware) access control.

The first main motivation of our work is to provide an access control that restricts the entities to do only what is allowed in the workflow, and to guarantee the process integrity. The second main objective of our framework is to support dynamic workflows which adapts to error conditions by, for instance, allowing services to create on the fly sub-workflows without changing the main workflow. Note that protecting the integrity of the processes and allowing the creation of dynamic workflows may be competing goals: it must be assured that the creation of the workflow can be done only by an “authorized” entity, and any misuse must be penalized. Thus, our framework must have a workflow driven access control in contrast to the commonly used mandatory (MAC), discretionary (DAC), or role-based access control (RBAC), which have been well-studied in the literature, see [5]. In addition, we need a system to log all actions of each participant executing the workflow for auditing purpose. As CML consists of different partners it is important to have an auditing system without assuming a central authority.

Summarizing the CML requirements, the main goal of this paper is to develop a framework that:

  • supports the specification of processes as workflows that can be created in a step wise manner using standard software engineering processes and tools.

  • constrain an entity using an application/services to obey a prescribed workflow with fine-grained authorization constraints (least privilege and need to access) and provides a formal background to guarantee process integrity.

  • allows entities participating in a workflow to have a choice for example, to accept (or reject) “contracts” or conditions,

  • allows services and entities executing a workflow to handle error conditions by supporting creation of dynamic workflows, and

  • provides accountability without assuming a central authority.

To achieve the goals described above, we contribute and extend our Petri Nets and Transition Contracts framework presented in [2] by:

  • Using SysML activity diagram to model the business or technical process of stakeholders.

  • Introducing open Petri Net places to exchange information between workflows.

  • Using timeout transitions that can trigger a transition, fire a timeout token after a predefined time expires.

  • Using of PNML to write and exchange Petri Net workflows between entities and users.

  • Introducing a private blockchain network for accountability purposes without assuming the central trusted authority.

The rest of the paper is structured as the follows: Sect. 2 presents our previous framework, Sect. 3 describes the contributions of this paper, extensions to existing framework and how we adapt it for the CML with a prototype implementation, Sect. 4 presents how our framework can solve a CML use case, Sect. 5 presents related work and at the end, Sect. 6 presents the conclusion and future work.

2 Background Work

In this section, we introduce Petri Nets based workflow specification and enforcement presented in [2].

2.1 Petri Nets for Workflow Specification

Petri Nets enable us to create workflows with properties like deadlock-free, guaranteed termination, separation-of-duties, etc. Properties of Petri Nets such as reachability, liveness (deadlock-free), and coverability [6,7,8] can be verified. Hierarchical Petri Nets can simplify the process of creating complex workflows by breaking them into smaller partial workflows.

In traditional Petri Nets (PN) (see [9]) there are places, tokens and transitions. A place in a traditional Petri Net can hold one or more tokens (Markings) of same type. Colored Petri Nets (CPN) (see [10]) is an extension of Petri Nets, and in CPN different types of tokens can exist in the same place. A transition may have one or more input places, and a place may have one or several tokens. A transition fires if its input places have sufficient tokens and as a result it produces tokens in output places. Entities executing the Petri Net workflow change their state from one place to another via a transition firing. Extensions of Petri Nets such as colored Petri Nets have enabled Petri Nets to represent different types of tokens in one place.

Fig. 2.
figure 2

(a) shows the initial state of a Petri Net workflow specification and (b) shows the state of the Petri Net after the first two transitions have fired.

Full size image

In our Petri Net model for workflows presented in [2], we extend Colored Petri Nets (CPN) by introducing the following additional concepts:

  • A Token in our Petri Nets can be a representation of permissions, endorsements, money (crypto coins), signature, or any information that is required for the workflow execution. We will use explicit token names (for example, oauth token) and explain their purpose wherever necessary to avoid confusion between different types of tokens used in use cases.

  • A special type of Petri Net place (called an oracle) that can receive tokens (information) from an external source and it is represented as star shape (filled with green color) in our Petri Nets. The Fig. 2 shows a simple workflow specified as a Petri Net. The oracle is represented as a star and all other places are represented as circles. A place that contains or holds a token is marked with a small black circle. The transitions waiting for tokens are presented as squares without patterns, and activated transitions ready for firing are shown as patterned squares. The Fig. 2(a) shows that the first two transitions are enabled (ready to fire) because the input places have tokens, and the Fig. 2(b) shows that those two transitions have fired and as a result produced tokens in the output places. An oracle is drawn usually on the boundary of a Petri Net to represent that the information is from an external source. Note: the term oracle is used in different computer science fields including cryptography, blockchain and smart contracts, etc. Our concept of an Oracle is similar to the Oracles introduced in Ethereum blockchain, i.e., it is used to receive external information into the workflow. An Oracle in our method need not be a contract that is accessed by other contracts as to get external information as described in [11, 12]. If a blockchain implementation is used then an external service can push some information into the blockchain, later an oracle is used to query that information. In other instances, an oracle in our Petri Net can have a predefined URL, and by querying that URL the Oracle may get the required information.

Workflows can be specified using Petri Nets, but we need a mechanism to enforce conditions that are written in the transitions of Petri Nets. For this purpose, we proposed to use smart contracts. Smart Contracts introduced in [13], have become popular with the advancements in blockchain technology. Smart contracts are often written to ensure fairness between participating entities even when one entity may attempt to cheat the other entity in arbitrary ways (see [14]). Ethereum [15], which has popularized the use of smart contracts defines a smart contract as “/a computer code that defines certain parts of an agreement and can self-execute if terms are met/”. Bitcoins uses a simple stack (or non-Turing complete language) language to express the rules and conditions for a successful transaction i.e., how new coins are produced and consumed. Ethereum uses a Turing complete language (Solidity [16]) to express complex contractual terms and conditions. Luu et al. [17] studied the security of running smart contracts based on Ethereum, and presented the problems in Ethereum’s smart contract language solidity; they also show some ways to enhance the operational semantics of Ethereum to make smart contracts less vulnerable. For our requirements both Bitcoin and Ethereum languages are not suitable. Bitcoin’s stack language is not flexible therefore, we cannot express workflow conditions on it. Ethereum’s solidity language could be vulnerable (see [17]), and we cannot verify such contracts. Therefore, a smart contract language that is flexible to specify conditions and at the same time verifiable is required. Some transitions within our Petri Net workflow have additionally a transition contract as shown in Fig. 3.

2.2 Transition Contracts

In traditional Petri Nets a transition fires when its input places has sufficient tokens. To implement a workflow driven access control system in Petri Nets, the transitions should be able to verify conditions and evaluate information encoded in the tokens. The conditions written on a single transition using a simple smart contract language is called a transition contract. We propose to use a simple guarded command (a conditionally executed statement) language (similar to [18]) to write transition contracts.

Fig. 3.
figure 3

Smart contract: Petri Net with transition contracts

Full size image

The Fig. 3 shows a simple Petri Net where two transitions (T1 and T2) have a pointer to the transition contracts (TC (a) and TC (b)) respectively. Note: smart contracts do not always have to run on blockchain, they can also be implemented between two or more parties without blockchain technology.

The properties (or rules) for each transition may be seen as small smart contracts that restrict the choices of the participants of the workflow for this step, or they impose additional conditions. The combination of few transition contracts allow us to create multi-step smart contracts: say, the first transition creates a token based on some conditions (which may verify authentication or authorization status of participants), and then the second transition produces an oauth token that can only be used in a subsequent transition in a particular way. The allowed actions, permissions of workflow participants are determined by the Petri Net and the next transition contracts. We propose to use the combination of Petri Nets and transition contracts to specify, enforce sequences of atomic transitions (transactions), and properties that must be satisfied in a workflow.

A transition performs three steps before firing:

  • First, it takes tokens from the input places (could be a normal place, open place or an oracle).

  • Next, it verifies the validity, properties of input tokens.

  • Finally, it evaluates the conditions described (as guarded commands) in the transition contract, and produces the output tokens in output places (could be a normal place, open place or an oracle).

An output produced by the transition contract can be a token representing information or a workflow for one or more entities.

3 Specifying and Enforcing Workflows in CML

In CML, services or applications may have been developed by different service providers, have different specifications and implement “equivalent” tasks differently. In addition, it is important to guarantee the process integrity, and provide workflow driven access control. This implies that the workflows must be specified at a higher layer, abstracting away from implementation details. For this purpose, first we need a high level workflow specification language to express a process in a given context as a workflow. The workflow specification language should be amenable to lightweight formal methods, so that the different parties can reason locally about them. Petri Nets as the workflow specification language is a used for the above mentioned reasons. In our previous work [2], we focused on applying our framework to the constrained devices of Internet of Things (IoT). The CML App is installed in devices such as smart phones and touch points, therefore we apply our framework in CML without any problems.

The integrity of the workflow is guaranteed without requiring a central enforcement authority or workflow engine. Instead, the owner of each CML provider enforces his own conditions on users to access his services by verifying that the user has the necessary tokens, including ones which demonstrate the successful completion of previous steps in the workflow. This service then also provides a token to the user which he can present to the service in the next interaction.

We believe that the way to secure a reliable, consistent and predictable set of rules in complex environments is using formal methods. This is also one reason for choosing Petri Nets as a specification language. Since some transactions have some further logic depending on the values of the tokens presented, we propose to specify Smart Transition Contracts (presented in Sect. 2) in a simple declarative language.

It is a complex task to design a process from scratch that uses different services from various providers. The general accepted method is to refine the specification in a step wise manner using software engineering tools such as the object management group (OMG) system modeling language’s (SysML) activity diagram presented in [19]. The OMG SysML is a general purpose graphical modeling language for specifying, analyzing, designing and verifying complex systems. In particular, it provides a semantic foundation for modeling system requirements, and the SysML’s activity diagram can be transformed intuitively into a Petri Nets model.

A workflow should handle error conditions to an extent, and we propose to use dynamic workflows. Dynamic workflows are created to handle special and error conditions, user choices, etc., by authorized entities (of the main workflow) without changing the goal or purpose of the main workflow. Note that protecting the integrity of the processes and allowing the creation of dynamic workflows may be competing goals: it must be assured that the creation of the workflow can be done only by an “authorized” entity, and any misuse must be penalized. Therefore, we also need a system to account (save or log) all activities performed by the participants of the workflow. To enable dynamic workflows and guarantee the process integrity within CML, we introduce to two extensions to our existing framework.

Fig. 4.
figure 4

WF (a) and (b) exchange information using Open Petri Net places.

Full size image

First, we propose to use Open Petri Nets (see [20]), which provide entry and exit points (via Open Petri Net places) to exchange information between workflows. Open Petri Nets [20] enable two or more workflows to exchange information in the form of tokens. For instance, Fig. 4 shows that WF (a) and WF (b) exchanging tokens via the open place (oa and ob). An open place exists on the boundary of the workflow, and the equivalence (=) sign identifies the entry and exit places between two workflows. The open place (oa) is an exit place for WF (a) and entry place for WF (b). The main difference between an oracle and an open place is: an oracle can receive information from external sources whereas, the open places are mainly used to exchange tokens between workflows. Open petri net places are particularly useful when creating the main workflow would like to create a dynamic workflow and exchange information with it.

Sometimes, a user or an entity may fail to complete a task in a workflow that is expected to be completed within a certain time. This could lead into an error condition (for example, a transition may wait forever to get a token in a required place). To solve this problem, we propose to use timeouts in Petri Net transitions i.e., after a predefined time expires, the transition executes set of predefined conditions and fire a timeout token. We call these transitions as timeout transitions. Timeouts in transitions should be used only when necessary, and timeout transitions can be triggered by a token in one of the input places. For example, consider a task (tsk1) that should be completed within 10 min, and this task can be initiated after transition (t1) produces a token in the place (a). The next transition (t2)’s is implemented as a timeout transition that is triggered when a token appears in place (a) i.e. the countdown starts and default conditions are executed to produce a token when the time expires after 10 min.

The CML is a centralized system but our framework uses a distributed blockchain network for accountability purposes. A private blockchain is used to set access control restrictions i.e., who is allowed to participate in the blockchain. For instance, the users when executing the workflow publishes status of every task that they are executing – i.e., status of transitions of the Petri Net workflow – in the private blockchain. The stakeholders will verify and approve the transactions in the blockchain, and this provides transparency and accountability in an immutable database without assuming a trusted centralized entity.

Finally, we need a standard method to exchange Petri Net workflows between users and CML entities. Weber et al. in [21] introduced Petri Net Markup Language (PNML) which is based on XML, and in this work we propose to use the PNML for writing, exchanging Petri Net workflows between different entities and users of CML.

3.1 Petri Net Based Workflow Enforcement

Our prototype implementation also demonstrates the feasibility of using Petri Nets to enforce workflows in a real system such as CML.

Assume that different stakeholders are providing their services as Representational State Transfer (REST) based web services through CML core services. The workflows are created by workflow experts, approved by the stakeholders and made available within a centralized CML repository. A participant can download the CML App and the required workflow from the CML repository, and then he may start executing the workflow. The CML front-end provides the communication interface between the CML App and the CML core services – standard security protocols are used to protect the communication channel. How participants authenticate with the CML front-end application is out of scope here. The enforcement of the Petri Net workflows is integrated with the CML App. The workflows being executed within the CML App run within a Trusted Execution Environment (TEE) and may contain secret material; we assume that the participants are not able to extract or modify any secrets from the workflow. For instance, to authenticate against a CML service the shared secret material can be used by a transition of the workflow.

The Python library called “SNAKES”, presented in [22] by Pommereau, is used to execute the Petri Nets workflows written in Petri Net Markup language (PNML). The SNAKES library is extended to support different types of Petri Net places such as oracles and open places, and to evaluate transitions with external conditions and produce the necessary tokens that will be required for subsequent transitions. In current implementation, the transition contracts are expressed with limited features of SNAKES library’s arc notations, expressions that can use native python functions to evaluate input tokens and produce required tokens.

4 A CML Use Case

A typical commuter in a cosmopolitan city has several transportation options such as flights, train network for intercity travel, public transport, car and bike sharing services including parking facilities within the city, and so on. The CML envisions to integrate mobility services, and provide a mobile/web application to its users with an objective to provide a comprehensive mobility service.

We describe a business mobility use case scenario of the CML where a company can enforce project specific travel restrictions, special conditions – such as on what situation an employee can take business class trips – on its employees.

Let us consider that two companies A and B work on a public-funded project, and due to the nature of the project the team members need to travel between two companies frequently. The companies A and B decide to use mobility services offered by CML to its team members. The CML’s workflow specification and enforcement module – described in the Sect. 3.1 – supports to enforce Petri Net based workflows.

Fig. 5.
figure 5

SysML activity diagram of CML business mobility use case

Full size image

The CML business mobility use case requirements are:

  • Companies A and B can enforce travel restrictions on employees.

  • All travel activities must be approved by the respective managers of participating companies, and in special cases the public funding project manager (mP) approval is also required.

  • Managers may specify special conditions whenever necessary in workflow specification i.e. decentralized decisions can be made.

  • Workflow should recover from error conditions for instance, re-booking or canceling should be possible.

  • Reimbursement of travel cost should be automated.

  • Data immutability should be available in an immutable database.

As the first step, the requirement engineering experts model the use case requirements using OMG SysML’s activity diagram. The open source modeling tool “Modelio” is used, and Fig. 5 shows the SysML activity diagram of the CML business mobility use case workflow: where an employee (e) is able to make a travel request which can be approved or rejected by his manager (mA), and in case of special request the public funded project manager (mP) must also approve. The CML calendar service provides information about the meeting such as location, time, etc. If the trip is approved, then the CML mobility service provides tickets to the employee via the CML app. The employee (traveler) may choose the transportation means (public transport, carsharing, etc), and accordingly the tickets are given to the employee via the CML app. Finally, the trip comes to an end; the reimbursement process begins after the trip has been completed successfully. Thanks to the CML core services, it is possible to provide such services to the users.

The business mobility process and conditions are discussed between the participating companies (A and B) and the public funding project manager. Later, workflow experts transform the SysML activity diagram into a Petri Net workflow specification as shown in Fig. 6.

Let us consider the following:

  • The CML app has access to CML core services including the CML calendar service.

  • The WF (a) and (b) as shown in Fig. 6 are available in the central repository and can be accessed by CML app i.e. the users are able to use the CML app to download required workflows and execute them.

  • The participants can make travel request by executing WF (a).

  • The CML services (such as mobility, parking, etc) provide tickets, parking lot information, visiting passes for authorized requests (similar to an oauth resource request).

Below, we describe step by step process of WF (a). In Fig. 6 the places and transitions are marked with identifier such as e (employee), mA (manager of Company A), mP (manager of the public funded project), cal (CML calendar service) and at1 (WF (a) transition 1), bt1 respectively.

Fig. 6.
figure 6

Business mobility use case Petri Net workflows

Full size image

  • A project meeting invitation with an identifier (mID) is generated by the project manager of company B (mB) in the CML calendar service, and the identifier is required by the employee (e) of company A to initiate the travel request using the CML app.

  • The employee (e) from Company A places a request as a token in the place (e) to travel to Company B for the meeting (mID). When a travel request is raised, the CML app starts to execute WF (a) as show in Fig. 6 WF (a).

  • The manager of Company A provides his approval in place (mA) with mID. The oracle place (cal) performs a GET request with meeting mID to the CML calendar service’s REST interface URL to retrieve event information such as location, time, etc.

  • The first transition (at1) of WF (a) evaluates the information token from the oracle (cal) and tokens from places (e and mA). In particular at1 evaluates whether the mID, employee email address and approval from his manager are valid or not. As this trip is a special trip, it requires additional approval from the public funding manager (mP). Given this special case, the transition (at1) fires a token in the Petri Net place (oa and in the next place of WF (a).

  • The CML workflow enforcement engine processes the token from the WF (a)’s open place (oa) and downloads the workflow WF (b) from CML repository to be executed in special cases. The project manager (mP) approves or rejects the trip request. WF (b)’s transition contract (bt1) evaluates the input tokens if valid, bt1 produces output tokens that instructs, provides the secret (similar to an oauth access-token) required by the transition at2 via the open place (ob).

  • When transition at2 receives the required secret information, it queries the respective CML mobility service to get the tickets.

  • In case of unforeseen circumstances (delay in public transportation, or due to illness) the traveler is able to request an alternative transportation option to the CML mobility service or cancel the existing trip via the CML app by placing a token in the oracle place (err). The transition (at3) evaluates the error token, if the traveler wants to end the trip, then it places a token in place (end) and places a cancellation request in open place (oc).

  • If the traveler requests alternative tickets, then transition (at3) places an error token to request new tickets in the open place (oc), this token is processed by dynamically created WF (c)’s transition (ct1). If the error conditions are acceptable (may require human intervention), then new tickets are delivered via the open place (od). Note: Fig. 6 shows the workflow only until this stage, the rest of the workflow steps can be executed with more transitions and places.

  • Thanks to the transition contracts in Petri Net based workflows, fine-grained access – such as, temporary access valid during the meeting period – can be granted to enter company B (for example, access to meeting rooms), reimbursements can be automated i.e., after a successful trip a waiting time is introduced using timeout transition, if the trip is not successful then a default process is initiated.

  • At the end, the organizer of the meeting is able to confirm the attendees through his CML mobile app, therefore the payment transition is activated such that payment to mobility providers, reimbursements to the employees can be handled appropriately.

A private blockchain is used in the CML for accountability reasons every Petri Net transitions’ input and output tokens are recorded as transactions on the blockchain. This feature provides data immutability and opportunity for future auditing in case of any fraud without a centralized trusted entity. There are several advantages for companies to enforce such business mobility conditions on its employees. The companies could restrict its employees from using transportation service for private purposes. Further, the employees can only use the cost effective transportation available. By automating this process, the overhead for the employees and its managers are reduced. The companies can satisfy regional policies such as reducing the carbon footprint.

5 Related Work

In the literature, we can find extensive work on the specification and enforcement of workflows; in particular, Bertino et al. in [23] studied how to model and enforce workflow authorization constraints such as separation-of-duties in workflows, but using a centralized workflow management system. Workflow based access control is also well-known (Knorr in [24] calls them “Dynamic access control”), but this requires a centralized WF enforcement engine. Basin et al. in [25] model the business process activities as workflows with a special focus on optimizing the authorizations permissions.

Petri Nets (see [9]) provide a graphical modeling tool used to describe processes performing an orchestrated activity, or in other words, a workflow (see [7]). Petri Nets have the advantage that many properties such as liveness (deadlock-freeness), reachability are easy to verify. (see [6, 8, 26]). Atluri et al. [27, 28] studied how to model workflows using Petri Nets, but did not describe the implementation details. Huang et al. [29] presented a web-enabled workflow management system, and Compagna et al. [30] presented an automatic enforcement of security policies based on workflow driven web application, but both works presented a centralized architecture. Heckel in [20] showed how open Petri Nets are suitable for modeling workflows spanning different enterprises.

In OAuth-2.0 [31] context an authorization server provides an oauth token (representing a permission) to the client to access a resource in the server. We have similar requirements in our method, for example, an authority of an entity in a given context can create, pass tokens to another; but, for the purposes of workflows, we need further types of tokens (not just permissions).

Linhares et al. in [32] presented an empirical evaluation of OMG SysML’s to model an industrial automation unit using the open source modeling tool ModelioFootnote 1 but not in the context of modeling workflows.

6 Conclusion and Future Work

In this paper we demonstrate an extension of [2] to enforce workflow-aware security in the Connected Mobility Lab (CML). We showed that our framework can support and handle the integrated business mobility use cases (where different mobility services work loosely coupled) to achieve a common goal. The extensions presented in this paper enable the main workflow to handle error conditions and exchange information between workflows. In many business applications, securing the integrity of processes is the most important security requirement. We demonstrated that our framework provides workflow-aware access control and also enforce the integrity of processes.

We believe that access control permissions should be granted to users in the form: “You are allowed to execute this task in this workflow” instead of “You are authorized to access this service during this period of time”. The permission to execute a step in a workflow depends on having executed the required previous steps.

We mention some future directions of this work: a simple verifiable language required to write transition contracts and a tool that can transform SysML activity diagrams into Petri Net workflows.