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

Secure Systems Research Group - FAU

A Pattern-Driven Process for Secure Service-Oriented Applications

Ph.D Dissertation Defense

Candidate: N. A. Delessy, Advisor: Dr E.B. Fernandez

March 2008


Agenda

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

• Related Work


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


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


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


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.


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


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


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


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


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


The Pattern-Driven Process

Software Lifecycle

StageActors 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


The Pattern-Driven Process

Software Lifecycle

StageArtifact

Artifact for Service-oriented applications as a composition of

servicesTransformations

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


The Pattern-Driven

Process


Example: Travel Agency


Example: Travel

Agency


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



Security goals/Trust Security Requirements Policy type

Confidentiality of stored information

SR1. Access to services and their operations must be controlled Access Control policies

SR2. Service requesters must be authenticated Authentication policies

Confidentiality of information in transmission

SR3. The contents of exchanged messages must be kept confidentialMessage-level confidentiality policies

Integrity of stored informationSR1. Access to services and their operations must be controlled Access Control policies

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

SR6. The contents of the received message must be authenticatedMessage-level authenticity policies

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 wayTrust establishment and trust propagation policies

SR9. Identity management and identity propagation must be clearly defined Identification policies

Non repudiation

SR10. Service requester cannot deny having sent a messageMessage-level non-repudiation policies

SR11. Accesses to a service must be loggedLogging policiesAudit policiesNon repudiation policies


The Security-Enabled

Metamodel for Service-

Oriented Applications



• Using the metamodel


The Security-Enabled Metamodel for

Service-Oriented Applications

• Using the metamodel


The Security-Enabled

Metamodel for Web

Services-Based

Applications


The Decision-Guiding Map of Security Patterns


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.


The Identity Provider Pattern

context FederatedIdentity

inv: forall(p | self.federatedAttributes->includes(p) implies

self.subject.localIdentity.localAttributes->includes(p))

inv: self.federatedAttributes->excludes(

self.subject.localIdentity.localAttributes.oclAsType(

PrivateAttribute))


Policy-Based Access Control Pattern


The Chain of Transformation Definitions

• PIM2PSM– Simple QVT Relations

• CIM2secCIM, PIM2secPIM and PSM2secPSM– Relations between models are not static Model weaving operation


PIM2PSM Transformation Definition

• Example: Relation InvRec2All


PIM2PSM

• Travel Agency Example: Generated PSM


PIM2secPIM Transformation Definition

• Travel Agency example:

• Produced relation


PIM2secPIM Transformation Definition

• Travel Agency example:

• Produced PIM


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.

• .


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.


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.


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?


Thank You!

Documents

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