Methodology and Tools for End-to-End SOA Security Configurations

Abstract

The configuration of non-functional requirements, such as security, has become important for SOA applications, but the configuration process has not been discussed comprehensively. In current development processes, the security requirements are not considered in upstream phases and a developer at a downstream phase is responsible for writing the security configuration. However, configuring security requirements properly is quite difficult for developers because the SOA security is cross-domain and all required information is not available in the downstream phase. To resolve this problem, we clarify how to configure security in the SOA application development process, and define the developer's roles in each phase. Additionally, supporting technologies to generate security configurations are proposed: Model-Driven Security and Pattern-based Policy Configuration. Our contribution is proposing a methodology for end-to-end security configuration for SOA applications and tools for generating detailed security configurations from the requirements specified in upstream phases model transformations, making it possible to configure security properly without increasing developers' workloads.

Security Problems of SOA Applications

“…Sometimes security is added at the time of integration of distributed applications. SOA applications are coupled over various protocols and network technologies, just adding security to software applications is not a realistic approach [6,22] because all the required security information is not available at the downstream phases [6,23]. This approach degrades implementing and maintaining the security of the system [24].…”

Domain-Specific Multi-modeling of Security Concerns in Service-Oriented Architectures

“…A methodology for an end to end SOA security configuration in proposed by [18]. The approach is model-driven, and makes use of templates to express identified security patterns, initially added as abstract keywords that represent security requirements at business level, and then at a service model level.…”

“…The SIM, although closer to topology modeling, fulfills an equivalent functionality to that of the WS-SecurityPolicy platform model in this work. Our approach and the one in [18] differ in that the latter is limited to security, and in, perhaps, the greatest strength in this proposal: the use of sepárate concern models to address each non-functional characteristic, a feature that aids reuse and modularity of design and implementation.…”

Semantic Service Matchmaking in the ATM Domain Considering Infrastructure Capability Constraints

“…It offers routing services to navigate the requests to the relevant service provider based on a routing path specification. Routing may be [6] itinerary-based, content-based, conditional-based defined manually [45] or dynamic [51]. In both cases the drawback is the minimal support for considering all functional and non-functional requirements of all service connections in the system.…”