A survey on automation of security requirements in service-based business processes <s> Security enforcement using aspect oriented programming concepts <s> Many crosscutting concerns in business processes need to be addressed already at the business process modeling level such as compliance, auditing, billing, and separation of duties. However, existing business process modeling languages including OMG’s Business Process Modeling Notation (BPMN) lack appropriate means for expressing such concerns in a modular way. In this paper, we motivate the need for aspect-oriented concepts in business process modeling languages and propose an aspect-oriented extension to BPMN called AO4BPMN. We also present a graphical editor supporting that extension. <s> BIB001 </s> A survey on automation of security requirements in service-based business processes <s> Security enforcement using aspect oriented programming concepts <s> Security is an essential requirement for business processes. However, we observe that security is mostly addressed at the technical implementation level and not at the design level. In a previous work we motivated the need to address security already in business process modeling. In this paper, we show how one could use Aspect-Oriented Programming (AOP) to enforce security requirements in a modular way. Starting from a business process model where security requirements are expressed using a profile mechanism we generate AspectJ [1] code, which enforces those requirements. This generation is based on a set of Model-to-Text transformation rules. As security is a typical example for crosscutting concerns the usage of aspects allows for a modular implementation, in which the implementation of the business process is separated from the implementation of the security properties. <s> BIB002
A seminal initiative in the area of business process security enforcement with aspect-oriented programming (AOP) is the AO4BPEL/AO4BPMN BIB001 . This work presents a middleware-based solution to support security requirements in WS-BPEL compositions. As WS-BPEL has not support for security, Charfi proposes a framework to integrate security requirements and web service composition specifications. To enforce this integrated specification, he proposed a framework composed of two main elements: a web service-based middleware, which provides support for reliability and security and a WS-BPEL process container, which also has an associated deployment descriptor. A security web service allows secure interactions between the WS-BPEL process and the participant services. This service provides essential security functions like cryptography. The process container wraps WS-BPEL processes and provides security support and this process container is implemented as a set of aspects. Finally, the deployment descriptor is a XML-based file responsible for specifying the security requirements of the business process activities and the needed security artefacts. The deployment descriptor is an essential component of Charfi's architecture. The descriptor contains all security requirements that have to be fulfilled at execution time. In a design point of view, a programmer uses the WS-BPEL definitions to specify the functional requirements of the system and use the deployment descriptor to define the security requirements. To better illustrate the strategy proposed by Charfi, Figure 12 presents a general overview of the AO4BPEL security enforcement framework architecture. Some important points should be highlighted. The deployment descriptor is used only for specific reasons, i.e., it is not responsible for the enforcement of the security requirements. In fact, in the proposed framework, the security middleware services are responsible for the security enforcement. Each WS-BPEL process is executed inside a process container and this container intercepts the execution of selected activities in the context of the business process, e.g., the invoke activity. These activities are directly related to the enforcement of security requirements in the system. Figure 12 shows the deployment descriptor connected to the WS-BPEL business process and this descriptor specifies that particular business activities should use reliability actions. To accomplish that, the process container intercepts invocations in the business process execution and an external middleware service is invoked to enforce the required action. Another important point in Charfi's approach is the adoption of the aspect-oriented paradigm to build a container that can be easily extended. The main idea is to add new security middleware services by creating relevant aspects, which can be done by an AO4BPEL or AO4BPMN designer. Based on this strategy, it is possible to add a new security middleware service without changing the implementation of the WS-BPEL engine. The main point of the AO4BPEL is the enforcement of the business process security requirements at execution level using AOP concepts. In practical terms, AO4BPEL proposes a security enforcement environment in which new security capabilities can be added, without requiring the adoption of other WS-BPEL orchestration engines or even updating the source code of the engine. In another related work, BIB002 shows how users can adopt the AOP in a modular way. This modularity is achieved with the use of the AspectJ and some transformations between the BPMN model to AspectJ code are proposed. The functional automation produces Java code that represents an executable version of the business process and the non-functional automation generates the AspectJ executable code. Additionally, BIB002 presents generated AspectJ codes to enforce common security requirements, such as confidentiality, integrity, binding of duties and authentication. The use of AspectJ to enforce security requirements in business processes is an interesting contribution of this work.