Securing Service-Oriented Architectures using a Model-driven Approach

1. Securing Service-Oriented Architectures using a Model-driven Approach Nelly A Delessy

2. Agenda • Introduction • Background • Problem statement • The methodology • Overview • Detailed Steps and Running Example • Related work • Anticipated contributions • Conclusions • Questions

3. Introduction • Service-Oriented Architecture (SOA): • considered to be the new phase in the evolution of distributed enterprise applications • In our more and more competitive business world, in which business needs and partnerships are changing constantly, the rapid evolution of business applications is a key factor in the success of an organization.

4. Introduction • Service-Oriented Architecture (SOA): • SOA has promised to provide enterprises with flexible and extensible architectures that would enable them to adapt their applications easily so that they remain competitive and compliant. • Most of the major software vendors sell SOA products such as Enterprise Service Buses (ESBs). • Even though there is a common acceptance of this concept, a real problem hinders the widespread use of SOA: A methodology to design and build secure SOA-based applications is still needed

5. Background: SOA • There is no official definition for SOA. The Open Group, the Object Management Group (which proposed MDA), and OASIS proposed their definition, and many books concerning SOA are available. • We summarized the principal characteristic of SOA: • Service-Oriented Architecture (SOA) is an architectural style in which a system is composed from a series of loosely coupled services that interact with each other by sending messages. In order to be independent from each other, each service publishes its description, which defines its interface and expresses constraints and policies that must be respected in order to interact with it. A service is thus a building block for SOA applications.

6. Background: SOA • This architectural style implements some principles [Erl05]: • Loose coupling between services • Service contract • Autonomy • Abstraction • Reusability • Composability • Statelessness • Discoverability • An implementation platform for SOA is the Web Services technology.

7. Background: MDA • Model-Driven Architecture (MDA) is a model-driven approach defined by the OMG. • It specifies three views in order to describe a system’s architecture • It proposes a process for software development. • MDA is based on a set of specifications (MOF, XMI, etc) in order to achieve interoperability and portability.

8. Background: MDA • MDA proposes three views (or viewpoints) to describe the architecture of a system: • The computation independent viewpoint focuses on the environment of the system and the requirements for the system. The details of the structure and processing of the system are hidden. • The platform independent viewpoint focuses on the structure and the operation of the system while hiding the details necessary for a particular platform. • The platform specific viewpoint combines the platform independent viewpoint with an additional focus on the detail of the use of a specific platform by a system.

9. Background: MDA • The MDA process • consists in a series of model transformations prior to obtaining the final implementation of a system. • First, a model of the system viewed from the computation independent viewpoint is created from the requirements for the system. This is the Computational Independent Model (CIM), also called the domain model or business model. A CIM shows the system in the environment in which it will operate and thus presents what the system is expected to do.

10. Background: MDA • The MDA process • Then a Platform Independent Model (PIM) is produced, it is a model of the system from the platform independent viewpoint. The requirements described by the CIM should be traceable to the PIM. • Then, a specific platform is chosen that enables implementation of the system with the desired architectural qualities. A model for that platform should also be available. Finally, the Platform Specific Model (PSM) is produced; it is a model of the system from the platform specific viewpoint.

11. Background: MDA • The MDA process • Transforming a PIM to a PSM is referred to as the ‘MDA pattern’ or ‘MDA mapping’.

12. Background: MDA • Meta-models • A meta-model (also referred to as a language) is the definition of a model. • The Four-layer metamodel Hierarchy • Each layer contains elements that are instances of the underlying layer

13. Background: MDA • MDA transformations • Meta-model mapping: • gives rules and/or algorithms expressed in terms of all instances of types in the meta-model specifying the PIM language resulting in the generation of instances of types in the meta-model specifying the PSM language. • it requires models to be instances of MOF meta-models.

14. Background: MDA • MDA transformations • Model marking: • An architect identifies model elements in the PIM which should be transformed in a particular way, given the choice of a specific platform for the PSM by marking those elements. • Marks represent a concept in the PSM, and are not intrusive to the PIM.

15. Problem Statement • The trust issue is more complex in inter-organizational context than it is in traditional fields of computing: • For example, the “hardware” or some “trusted computing base” is blindly trusted when designing an operating system. In the same way, one can easily establish a trust relationship with the “enterprise directory” in the case of a single organization’s system. Comparatively, it is much more complicated to establish trust dynamically across principals from different organizations.

16. Problem Statement • Furthermore the channels of communication between the participating entities in a SOA application are much more vulnerable: • Compared to operating systems or within the boundaries of an organization’s computer network

17. Problem Statement • Many efforts have been made to alleviate the security vulnerabilities that were introduced in the complex context of SOA applications. • They principally consisted in the production of numerous, often overlapping security standards by the industry actors. • But there is still no clear view of how to use them in order to produce secure SOA applications. • In this dissertation, we investigate the production of secure SOA applications. In particular, we provide an approach to build secure SOA applications that takes into account the new security issues introduced by the complexity of SOA-based applications.

18. The methodology: Overview • We build upon two different approaches to secure SOA applications: • model-driven development • The use of security patterns. • Since the basic security mechanisms are not new, we use security patterns to describe their structure and behavior. • Then we can derive more complex security solutions that are adapted to the SOA context. The result is a map of layered security patterns.

19. The methodology: Overview • Finally, since we use a particular format for our patterns that includes semi-formal UML models, we leverage on the model-driven architecture approach, which allows us to semi-automatically produce a secure design for a particular SOA application.

20. The methodology: Overview • The main benefit of this approach: • it decouples the application domain expertise from the security expertise that are both needed to build a secure application • It is usually difficult for non-security specialists to design a secure application. • On the other hand, a security expert would have to become an expert in an application’s domain model in order to understand where to apply security mechanisms and what security mechanisms are adequate.

21. The methodology: Overview • With our approach, the security expertise is embodied in the security patterns, and the model-driven engineering approach facilitates the integration of those patterns’ solution into the application design and implementation. • Thus, the application designers/developers can add security to their applications easily.

22. The methodology: Detailed Steps and Running Example • A key idea in our dissertation is to describe the SOA architectural style from the MDA viewpoints. • We propose the following framework to secure SOA applications.

23. The methodology: Detailed Steps and Running Example

24. The methodology: Detailed Steps and Running Example • A SOA metamodel has been defined using the standardized MOF language (, or a UML Profile? work in progress): • An application architect can then use any UML tool that has charged the SOA metamodel as a library to design its application. The result is a SOA application platform independent model, which can be easily understood by our tool. At this point, it is not yet secure.

25. The SOA metamodel (work in progress):

26. Use Case diagram the travel agency: (work in progress)

27. Conceptual model (CIM) for the travel agency: (work in progress)

28. Activity Diagram for the travel agency, for the use case Reserve Hotel: (work in progress)

29. Detailed Class Diagram (PIM) for the travel agency: (work in progress)

30. The methodology: Detailed Steps and Running Example • A security-aware application architect (who is not necessarily a security expert) uses the map of abstract patterns to select which security pattern to apply. He uses the human-only understandable part of the patterns (consequences, context, etc) to make relevant decisions.

31. Map of abstract security patterns for SOA :

32. The methodology: Detailed Steps and Running Example • The abstract security patterns solutions are automatically incorporated into the SOA application platform independent model, according to our rules for incorporating security patterns’ solutions to models.

33. The methodology: Detailed Steps and Running Example • We need: • The SOA security pattern metamodel: • The OMG proposed a metamodel for business pattern: we want to add to that: • The notion of pattern “realization” (they do have pattern inheritance and pattern composition) • The transformation specification from unsecure SOA PIM to secure SOA PIM, using the security patterns

34. SOA security pattern metamodel (in progress):

35. The methodology: Detailed Steps and Running Example • Before the transformation, the architect marks its unsecure SOA PIM. This is done through a dialog from the tool to the architect: • For each selected pattern: • For each SOAElement in the pattern • Ask to which specific instance(s) of a SOAElement the pattern should be applied to • Mark those specific instances selected by the architect • End For • End For

36. The methodology: Detailed Steps and Running Example • We need: • The transformation specification from unsecure SOA PIM to secure SOA PIM, using the security patterns (work in progress): • Source model : unsecure SOA PIM • For each selected security pattern • Insert all SOASecurityElements to the SOA PIM • Insert all Associations from the pattern for which all ends are SOASecurityElements • Insert those Associations from the pattern for which one end is an SOAElement between the corresponding SOAsecurityElement(s) and each marked SOAElement from the SOA PIM • End For • This transformation could be described using the QVT standard?

37. example of the security pattern selected by the architect:

38. resulting model (secure SOA PIM) Work in progress:

39. The methodology: Detailed Steps and Running Example • A MDA mapping is then automatically realized, according to two sets of rules: • 1) a MDA mapping between the SOA metamodel and the web-services metamodel, • 2) the set of relationships between patterns of our map that are of the “implements” type. • Since platform security solutions evolve constantly, our approach provides flexibility to add/remove patterns from our tool. Also, since the patterns’ solutions are written in the UML language and using our SOA metamodel, they can be easily exportable/distributable (using XMI) by different entities and still remain interoperable. The result of this step is a secure model for a particular web service application.

40. The web services metamodel (work in progress)

41. The methodology: Detailed Steps and Running Example • sets of rules: • 1) a MDA mapping between the SOA metamodel and the web-services metamodel: • Service  Web Service • Message  InputMessage, OutputMessage,… depending on the role of the service (consumer or provider) • … • The result is the insertion of a corresponding security pattern for web services (Liberty Alliance Identity Federation) to the model • A final transformation could have generated more concrete artifacts: WSDL, BPEL, WS-policies, XACML rules, but this is not in the scope of our work

42. Related Work • Securing SOA applications or web services: • Based on a formal model ([10]) • Based on AOP ([11]): They propose to extend BPEL to insert pointcuts. • A whole process using patterns [13], but not detailed, and does not take advantage of the MDA approach. • Addressing non-functional aspects in SOA using a metamodel, ([15]) but it does not address high-level security issues

43. Related Work • Using MDA to secure SOA: • In [1], a model driven approach to secure web services is proposed, but it focuses on access control, and by extending OCL (Object Constraint Language) to define access control policies that are later transformed into XACML policies. In our approach, we use a standardized MOF language to achieve interoperability. • [2] uses an MDA approach to include security during the whole design process. They define UML security intentions that are later transformed into platform specific security mechanisms. But they do not take advantage of the SOA nature of the application to be secured, their approach could be applied to any type of application.

44. Related Work • Using patterns and MDA to secure SOA applications: • In [9], they present low-levels patterns that can be used at the message exchange level, but do not secure higher levels (at the business process levels,..), so that they do not address such security issues such as trust establishment between partners, propagation of identities. They use concepts from Model-driven development to propose refined views for SOA applications but do not take advantage of the MDA standards to detail how to do the model transformations.

45. Anticipated Contributions • Our approach to secure SOA applications builds upon two independent approaches, so the contributions of this research have value of their own and could be used in other methodologies or for different purposes. Those contributions include: • A MOF metamodel for SOA applications (SOA PIM): work in progress • A MOF metamodel for web services-based applications (WS PSM): work in progress • A map of security patterns for SOA and web services-based applications, and a corresponding catalog of security patterns: done

46. Anticipated Contributions • A marking strategy for including security patterns into SOA applications: work in progress • A MDA mapping from the SOA PIM to the WS PSM: work in progress • The methodology itself: it can be abstracted and be applied to different architectural styles: done

47. Conclusions • In this presentation, we presented a novel approach to secure SOA applications. • Since security must not be considered as an isolated aspect, but as an aspect present in all stages of a system development, we rely on the MDA approach. • At the same time, we address the non-functional requirements separately from the functional requirements by embodying the security knowledge from security experts in the domain, in the form of security patterns.