1 / 36

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

  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.

Download Presentation

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

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

  13. The Pattern-Driven Process

  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

  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->includes(p) implies self.subject.localIdentity.localAttributes->includes(p)) inv: self.federatedAttributes->excludes( self.subject.localIdentity.localAttributes.oclAsType( 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!

More Related