securing service oriented architectures using a model driven approach l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Securing Service-Oriented Architectures using a Model-driven Approach PowerPoint Presentation
Download Presentation
Securing Service-Oriented Architectures using a Model-driven Approach

Loading in 2 Seconds...

play fullscreen
1 / 47

Securing Service-Oriented Architectures using a Model-driven Approach - PowerPoint PPT Presentation


  • 122 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Securing Service-Oriented Architectures using a Model-driven Approach


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
agenda
Agenda
  • Introduction
  • Background
  • Problem statement
  • The methodology
    • Overview
    • Detailed Steps and Running Example
  • Related work
  • Anticipated contributions
  • Conclusions
  • Questions
introduction
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.
introduction4
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
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 soa6
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
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 mda8
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 mda9
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 mda10
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 mda11
Background: MDA
  • The MDA process
    • Transforming a PIM to a PSM is referred to as the ‘MDA pattern’ or ‘MDA mapping’.
background mda12
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
background mda13
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 mda14
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
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 statement16
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 statement17
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
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.
the methodology overview19
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.
the methodology overview20
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.
the methodology overview21
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.
the methodology detailed steps and running example
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.
the methodology detailed steps and running example24
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.
the methodology detailed steps and running example30
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.
the methodology detailed steps and running example32
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.
the methodology detailed steps and running example33
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
the methodology detailed steps and running example35
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
the methodology detailed steps and running example36
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?
the methodology detailed steps and running example39
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.
slide40

The web services metamodel

(work in progress)

the methodology detailed steps and running example41
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
related 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 work43
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 work44
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
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 contributions46
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
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.