1
  A Pattern-Driven Process for Secure
Service-Oriented Applications Ph.D
Dissertation Defense

• Candidate N. A. Delessy, Advisor Dr E.B.
  Fernandez
• March 2008

2
Agenda

• Introduction
• Problem Statement
• Methodology and Overview of the Solution
• Summary of Contributions
• Related Work

3
Agenda

• Contributions
• The Pattern-Driven Process
• Security-Enabled Metamodels for Service-Oriented
  and Web Services-Based Applications
• The Decision-Guiding Map of Security Patterns and
  its Corresponding Catalog
• The Chain of Model Transformation Definitions
• Conclusions and Future Work

4
Introduction

• Problem Statement
• Service-Oriented Architecture (SOA) considered to
  be the new phase in the evolution of distributed
  enterprise applications
• SOA could enable the design and realization of
  flexible applications across multiple
  organizations
• Security issues associated with SOA
• trust establishment among actors in an
  inter-organizational context
• no central authority
• users may not be known in advance
• channels of communication more vulnerable

5
Introduction

• Problem Statement
• Actual solutions
• Production of numerous, often overlapping
  security standards by the industry
• ? But there is no clear view of how to use them
• Security mechanisms and schemes proposed for SOA
  and web services
• ? They are not new, they are used in current
  distributed systems
• A real problem hinders the widespread use of SOA
  A methodology to design and build secure
  service-oriented applications is needed

6
Introduction

• Methodology and Overview of the Solution
• We adapt the methodology in Fer06b,Fer06c
• Our process builds upon two different approaches
  to secure service-oriented applications
• model-driven engineering
• the use of security patterns.

7
Introduction

• Methodology and Overview of the Solution
• Security patterns are selected and applied at
  each step of the development process.
• We propose the use of a structured map
• ?Their selection is rendered easier
• Their application are automated since our
  patterns are described using UML models
• In order to validate our process, we apply it to
  a real world example a travel agency system

8
Introduction

• Summary of Contributions
• The Pattern-Driven Process
• describes in detail the different activities and
  artifacts produced at each step of the
  development
• Security-Enabled Metamodels for Service-Oriented
  and Web Services-Based Applications
• Allow the description of service-oriented and web
  services-based applications, with an emphasis on
  security, and in a flexible way, thanks to their
  security interfaces

9
Introduction

• Summary of Contributions
• The Decision-Guiding Map of Security Patterns and
  its Corresponding Catalog
• Identified patterns that covered all layers and
  policy types
• Wrote and publish some of them
• The Chain of Model Transformation Definitions
• Described using the OMG standard QVT

10
Related Work

• Several approaches have been presented to secure
  service oriented applications
• Many use a formal approach, but they are
  applicable in very specific cases
• e.g. Yua04 addresses low-level aspects of
  security at the discovery phase of web services
• Ala04 proposes a model-driven approach that
  extends OCL to define access control policies
• Nak05 uses a MDA approach, but a low-level only

11
Related Work

• Several approaches have been presented to secure
  service oriented applications
• Char05, Ray04 are Aspect-Oriented approaches
  to secure web services compositions, by resp.
  extending BPEL to insert pointcuts and defining
  model weaving operations
• the security expert would need to know resp. BPEL
  language or the unsecure application model
• Gut06 presents a whole process to secure web
  services-based systems
• Not detailed, no mention of automatic
  transformations

12
The Pattern-Driven Process
Software Lifecycle Stage Actors MDA viewpoint Artifact Description of the artifact
Analysis Business analysts Computational independent CIM Describes the problem space (customer needs, a.k.a. requirements)
Design Architects Platform independent PIM Describes how the chosen architectural style resolves the problem (i.e. in terms or components and connectors)
Refined Design ArchitectsDevelopers Platform specific PSM Describes how the problem is resolved using the chosen platform
Coding Developers Runtime execution Code/Configuration files How the specific language and (virtual) machine resolves the problem
13
The Pattern-Driven Process
Software Lifecycle Stage Artifact Artifact for Service-oriented applications as a composition of services Transformations
Analysis CIM UML conceptual class diagram, activity diagram derived from Use cases CIM to PIM (1) is manualCIM2secCIM is a simple automated operation
Design PIM Class diagram in terms of services, activity diagram describing the service compositions PIM2secPIM, and PIM to PSM (PIM2PSM) are automated
Refined Design PSM Class diagram describing web services and activity diagram describing the web services interactions PSM2secPSM is automated, PSM to code is semi-automated
Coding Code/Configuration files WSDL files, BPEL files, XACML rules
14
The Pattern-Driven Process
15
Example Travel Agency
16
Example Travel Agency
17
The Security-Enabled Metamodel for
Service-Oriented Applications

• Survey of existing SOA metamodels
• A security-enabled metamodel, not a secure
  metamodel
• For enhanced flexibility security patterns can
  be added dynamically
• Includes a simple security interface
• Designed from the security requirements for
  service oriented applications

18
The Security-Enabled Metamodel for
Service-Oriented Applications
Security goals/Trust Security Requirements Policy type
Confidentiality of stored information SR1. Access to services and their operations must be controlled Access Control policies
Confidentiality of stored information SR2. Service requesters must be authenticated Authentication policies
Confidentiality of information in transmission SR3. The contents of exchanged messages must be kept confidential Message-level confidentiality policies
Integrity of stored information SR1. Access to services and their operations must be controlled Access Control policies
Integrity of stored information SR2. Service requesters must be authenticated Authentication policies
Integrity of information in transmission SR5. A service must verify that the contents of received messages have not been modified during their transit. Message-level integrity policies
Integrity of information in transmission SR6. The contents of the received message must be authenticated Message-level authenticity policies
Integrity of information in transmission SR7. A service must verify that the received messages have not been replayed. Message freshness policies
Trusted participants SR8. Services and principals must be trusted only in a determined way Trust establishment and trust propagation policies
Trusted participants SR9. Identity management and identity propagation must be clearly defined Identification policies
Non repudiation SR10. Service requester cannot deny having sent a message Message-level non-repudiation policies
Non repudiation SR11. Accesses to a service must be logged Logging policiesAudit policies Non repudiation policies
19
The Security-Enabled Metamodel for
Service-Oriented Applications
20
The Security-Enabled Metamodel for
Service-Oriented Applications

• Using the metamodel

21
The Security-Enabled Metamodel for
Service-Oriented Applications

• Using the metamodel

22
The Security-Enabled Metamodel for Web
Services-Based Applications
23
The Decision-Guiding Map of Security Patterns
24
The Corresponding Catalog of Security Patterns

• Examples
• The Identity Provider Pattern
• allows the formation of a dynamically created
  identity within an identity federation consisting
  of several service providers. Therefore, identity
  and security information about a subject can be
  transmitted in a transparent way for the user
  among service providers from different security
  domains.
• The Policy-Based Access Control Pattern
• decides if a subject is authorized to access an
  object according to policies defined in a central
  policy repository.

25
The Identity Provider Pattern

• context FederatedIdentity
• inv forall(p self.federatedAttributes-gtincludes
  (p) implies
• self.subject.localIdentity.localAttributes-gtinclud
  es(p))
• inv self.federatedAttributes-gtexcludes(
• self.subject.localIdentity.localAttributes.oclAsTy
  pe(
• PrivateAttribute))

26
Policy-Based Access Control Pattern
27
The Chain of Transformation Definitions

• PIM2PSM
• Simple QVT Relations
• CIM2secCIM, PIM2secPIM and PSM2secPSM
• Relations between models are not static
• ?Model weaving operation

28
PIM2PSM Transformation Definition

• Example Relation InvRec2All

29
PIM2PSM

• Travel Agency Example Generated PSM

30
PIM2secPIM Transformation Definition

• Travel Agency example
• Produced relation

31
PIM2secPIM Transformation Definition

• Travel Agency example
• Produced PIM

32
Conclusions

• Benefits
• The process decouples the application domain
  expertise from the security expertise that are
  both needed to build a secure application.
• ? The inclusion of security during the software
  development process becomes more convenient for
  the architects/designers.
• ?Understanding security patterns from their
  human-readable description and knowing how to use
  the security-enabled metamodels are sufficient
  skills to use our process.
• .

33
Conclusions

• Benefits
• The insertion of security is semi-automated and
  traceable.
• ? The process is flexible and can easily adapt to
  changing requirements.
• Given that SOA was developed in order to provide
  enterprises with modular, reusable and adaptable
  architectures, but that security was the
  principal factor that hindered its use, we
  believe that our process can act as an enabler
  for service-oriented applications.

34
Future Work

• Identification and writing of more security
  patterns at all levels, in order to cover all
  security policies.
• Implementation into a tool. It should be able to
  make accurate suggestions of security patterns
  during the development of an application using
  all relationship types. Additionally, many MDA
  frameworks exist. The model transformation
  specifications should be implementable easily
  using one of those.

35
Future Work

• Our results consist in the design of a software
  development process for secure service-oriented
  applications. However, it would be valuable to
  abstract this process so that it could be
  architectural-style-independent, not only
  applicable to service-oriented applications.
• Finally, we need to investigate ways to validate
  our process. In particular, this leads to the
  problem of security patterns validation, which is
  resolved using methods in Jur02. But how can we
  verify that their application produces a secure
  design?

36
Thank You!