secure systems research group - fau securing service-oriented architectures using a model-driven...

Secure Systems Research Group - FAU

Securing Service-Oriented Architectures using a Model-driven Approach

Nelly A Delessy


Agenda

• Introduction• Background• Problem statement• The methodology

– Overview– Detailed Steps and Running Example

• Related work• Anticipated contributions• Conclusions• Questions


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.


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


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.


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.


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.


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.


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.


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.


Background: MDA

• The MDA process– Transforming a PIM to a PSM is referred to as the ‘MDA

pattern’ or ‘MDA mapping’.


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

MetaLevel

Description Example 1 Example 2

M0 Run-time instances

Objects “Nelly Delessy”’s record in Employee table

M1 Model User model (with concrete classes, etc)

Employee table with name, address columns, etc

M2 Meta-model UML Relational model: Relations, rows, columns, etc

M3 Meta-metamodel MOF MOF


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.


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.


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.


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


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.


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.



• 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.



• 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.

•



• 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.


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.



1. 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.


The SOA metamodel (work in progress):


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


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


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


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



2. 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.


Map of abstract security patterns for SOA :



3. 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.



3. 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


SOA security pattern metamodel (in progress):



3. 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



3. 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?


example of the security pattern selected by the architect:


resulting model (secure SOA PIM)

Work in progress:



4. 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.


The web services metamodel

(work in progress)



4. 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


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


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.


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.


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


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


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.

secure systems research group - fau securing service-oriented architectures using a model-driven...

Documents