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. Model-Driven Security. Pattern-based Policy Configuration. 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 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. 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). 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. 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.

2. Supporting Technologies  Model-Driven Security (MDS):  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.

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, 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 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. 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. 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. 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 Top-Down role assignment Bottom-Up role assignment Bottom-Up role assignment Rule-Based 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: 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 idRequester(X) :- component(X). ∀ X extIdRequester(X) :- compositeService(C, 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: 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 allowedIdRequester(X, Id) :- component(X). ∀ X extIdRequester(X) :- compositeService(C, 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.