140 likes | 351 Views
Methodology and Tools for End-to-End SOA Configurations. By: Fumiko satoh, Yuichi nakamura, Nirmal K. Mukhi, Michiaki Tatsubori, Kouichi ono. Brief Outline. Service Oriented Architecture (SOA) is useful for enterprise business processes, because SOA can change the processes flexibly.
E N D
Methodology and Tools for End-to-End SOA Configurations By: Fumiko satoh, Yuichi nakamura, Nirmal K. Mukhi, Michiaki Tatsubori, Kouichi ono.
Brief Outline • Service Oriented Architecture (SOA) is useful for enterprise business processes, because SOA can change the processes flexibly. • Security properties are not considered until the downstream development phases and the developers at this phase do not have sufficient information to create correct configurations. • This paper proposes a security configuration process and defines responsibilities for developers. It also proposes 2 supporting technologies to create concrete configurations: • Model-Driven Security. • Pattern-based Policy Configuration. • They also discuss about the background and problem in the current configuration processes, the End-to-End security configuration process, supporting technologies and related work
SOA Security 1. Security Domain Federation • Integration of different security technologies to secure all of the SOA application is called the security domain federation. • Web Services Security (WS-Security) proposes a framework for a security federation into which various security technologies can be integrated. • To exchange secured messages using WS-Security, a requester and a provider should share a common key as a security token. • WS-Security can exchange different kinds of security tokens using an intermediary server called a Security Token Service (STS). • The configuration for a security domain federation can be quite complex, because developers must fully understand the federation platforms including the STS.
2. Problems of Current Security Configuration • WS-Security is flexible and extensible, and its configuration is quite difficult for users. • Steps involved in the current application process is as follows: • A business analyst clarifies the business requirements and creates the business process model. • A software architect designs service assemblies to satisfy the business requirements and creates the service model. • A developer develops and tests atomic services. • An assembler assembles the atomic services to implement the application according to the service model created by the software architect. • A deployer deploys the application to the platform.
End-to-End Security Configuration 1. Methodology of Security Configuration • In the process of security configuration the following information can be handled in each phase: • A business analyst is responsible for clarifying the business-level requirements, so the security requirements should be clarified as a business-level policy defined by the business processes. • A software architect creates a concrete service model to satisfy the business process model, and hence the security requirements for the composite services should be specified in the service model. • An assembler creates security configuration files for each atomic service to meet the security requirements from Phase (2). • A deployer sets up the platform that runs the services for secure service execution, and deploys the configurations to the platform. • Developers have no role in configuring the security.
Model-Driven Security (MDS): MDS is a technology to generate the concrete security configuration files by model transformations from the abstracted security requirements specified by a software architect. Pattern-based Policy Configuration:supports a software architect in specifying the security requirements on composite services. 2. Supporting Technologies
Model-Driven Security 1. Security Intents • In the SOA application development process a software architect deals with a service model that is independent of the platform infrastructure. • Following two service models are assumed to be used by software architects: • UML 2.0 Profile for Software Services • Service Component Architecture (SCA) 2. Security Configuration Generation • Security Infrastructure Model (SIM) is introduced to hold the platform information required for concrete configuration generation. • MDS can generate the concrete and detailed security configurations for platform environments without writing configurations by hand, and it is a great help for assemblers.
The model transformation for policy generation has the • following steps: • The required security assertion templates are selected for the security intents, • Variables in each security assertion template are assigned values extracted from the SIM of the platforms where the application will be deployed, and • A security policy is generated by filling in the parameters of the security policy template with the value-assigned security assertion templates.
Pattern-based Policy Configuration 1. SCA & SCA Policy • The content & linkage of an SCA model application are called composites. • Composites consists of components, services & references.
2. Security Intent Patterns • To meet end-to-end requirement each component needs to be configured in a particular manner. • Consider an example pattern which has roleA & roleB : pattern : roleA(X), roleB(Y), constraints(X, Y) • The constraints between elements of roleA and roleB can be specified in a pattern as: ∀X∃Y path(X, Y), roleA(X), roleB(Y). • Two patterns are used for security domain: • Authentication Pattern : This pattern defines roles to apply authentication requirements to a composite. • Authorization (access control) Pattern : This pattern defines roles to limit access to a specified component.
3. Pattern application Rules • Three Scenarios for role assignment : • Top-Down role assignment • Bottom-Up role assignment • Rule-Based role assignment • Two application rules for the security patterns: • Recursive Authentication Rule : This applies the roles of an authentication pattern to a composite that has a recursive structure. The application rules are expressed as predicate logic: ∀X idRequester(X) :- component(X). ∀X extIdRequester(X) :- compositeService(C, X). • Recursive Access Control Rule : This is a rule for the access control pattern. This rule has the following rules for role assignments: ∀X allowedIdRequester(X, Id) :- component(X). ∀X extIdRequester(X) :- compositeService(C, X). • Pattern-based approach reduces the costs of role assignments and guarantees the validity of the roles for a component which has a recursive structure.
Conclusion • This article proposes a methodology for the configuration of security requirements and also defines the roles of the developers. • MDS assure that security requirements from the business level are satisfied and the developers can concentrate on their own responsibilities while configuring for security.