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
  systems 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

MetaLevel Description Example 1 Example 2
M0 Run-time instances Objects Nelly Delessys 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
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
  organizations 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 organizations 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 applications 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

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