Modeling Security for Service Oriented Applications Siming Kou
Muhammad Ali Babar
Amit Sangroya
Shanghai Fandi Information Ltd. Caoxi North Street367 Xuhuiqu,Shanghai China +86 18631257468
ITU Copenhagen Copenhagen, Denmark +45 7218 5107
IIIT Hyderabad Hyderabad, India +91 9949160657
[email protected]
[email protected]
[email protected] ABSTRACT Security is an important quality attribute for Service Oriented Architecture (SOA) based system. However, there is no sufficient support for modelling security-centric concerns for SOA based application. This paper presents a metamodel called SoaML4Security, which introduces QoS concepts into Service oriented Modelling Language (SoaML) in order to support the modelling of security aspect. We motivate the need of extending SoaML for modelling security concerns from different viewpoints. We describe the process of developing the metamodel, which can support Model Driven Engineering (MDE) approach for service-oriented applications. The use of the extended metamodel has been demonstrated by modelling a real world service-oriented application for security requirements. Categories and Subject Descriptors D.2.11 [Software Architectures]: Data Abstraction, Domainspecific architectures, Information hiding, Languages (e.g., description, interconnection, definition), Patterns (e.g., client/server, pipeline, blackboard). General Terms Security, Standardization, Verification. Keywords SOA, SoaML, QOS, Security, MDE. 1. INTRODUCTION In the last few years, Service Oriented Architecture (SOA) has become quite common style of designing software architectures of distributed enterprise systems. However, because of the design complexity and distributed nature of development, the security of the SOA based application is a challenging research problem. Security can be considered as one of the most important quality attributes. The Service oriented Architecture Modelling Language (SoaML) [1] has been designed to support the modelling of service oriented architecture design. However, SoaML does not incorporate the concepts of quality attributes. This paper presents a metamodel, which extends SoaML for modelling security for SOA based system. The concept quality of service (QoS) is specified by Object Management Group (OMG) standard called Unified Modelling Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. "ECSA 2010, August 23-26, 2010, Copenhagen, Denmark. Copyright (c) 2010 ACM 978-1-4503-0179-4/10/08 ...$10.00."
Language (UML) profile for Modelling Quality of Service (QoS) and Fault Tolerance Characteristics and Mechanisms [2]. The QoS UML profile has defined the basic concepts of quality of services, such as QoSCategory, QoSCharacteristic, and QoSConstraint. QoSCategory specifies the category of quality attributes such as security, performance, usability. In this way, QoS provides a way to model the quality attributes for services. The security of SOA based systems can be visualized from three different angles: the security of the organization, the security of service and the security of service interaction. The security metamodel proposed in this paper is designed to cover these three viewpoints in order to separate the concerns at each design layer. Each perspective of this metamodel emphasizes on a different security attribute. The security attributes defines security policies which specifies the rules for secure action and privilege of action participants. The service provider and service consumer must interact based on security service contract defined by security attributes. The security service contract specifies the security policies which the service provider and service consumer should follow. For different service participants, the same security attribute could hold different security service contract which means a security attribute can provide many manners of security strategy. We present a technology independent Metamodel for modelling different perspectives of security of SOA based application. This Metamodel extends SoaML with security viewpoints to support model-driven engineering (MDE) approaches to designing and building SOA based applications. We explain the process of developing the proposed metamodel, describe the new constructs introduced into SoaML, and illustrate its use by modelling security for a real SOA based industrial application.
2. BACKGROUND Software architecture usually incorporates and represents both functional and non-functional requirements of a system. Functional requirements represent the desired features, while nonfunctional requirements, also called quality attributes, define various properties such as security, performance, and usability. Quality attributes should be considered throughout the development lifecycle. Service-orientation design principles specify the features of a service: reusable, composable, autonomous, stateless, discoverable, loosely coupled, location transparent [3]. A single service fulfills a piece of well-defined business functionality. “Metamodeling is the analysis, construction and development of the frames, rules, constraints, models and theories applicable to and useful for modeling a predefined class of problems.” [4].
Model is an abstraction of objects in the real world. A model is expected to conform to certain metamodel as a programming language conforms to its grammar. The Object Management Group (OMG) provides a four layered framework for metamodeling [2]. The top level of this framework called M3 is the Meta-Metamodel layer, which specifies the basic concepts of the metamodel. The next layer, M2, is Metamodel, which extends the MOF model in M3 layer. M1 Layer, following its metamodel, represents established Model based on specific domain. Finally, M0 layer is Information layer, which is the run time instance of the model. SOA Modeling Language (SoaML) extends the UML2 metamodel for modeling services to support Model-Driven Development (MDD) approach. Figure 1 shows the Security Metamodeling for SOA mapping onto the Four-layer Metamodeling framework mapping using MDD approach. The quality of service plays an important role in SOA approach, especially in service discovery, selection and substitution [5]. Hence, in design time except functionality, the quality of a service is also a significant factor for architect to decide which services must be selected or to be composited and whether a given sequence of interactions can provide the requested quality [6]. M3 Layer MOF 2.0 Meta-meta Model M2 Layer SoaML Metamodel M1 Layer
Extended
SoaML4Security Model
Is instance of M0 Layer Information
QVS Security
Figure 1. MDE Approach for Metamodeling For the run time, the service consumer can select a service based on the required functionality and quality of service specified in service contract and the service provider must not only satisfy the functionality but also the quality of service specified in service contract. The quality of service (QoS) metamodel is based on the OMG standard called UML profile for Modelling Quality of Service (QoS) and Fault Tolerance Characteristics and Mechanisms (Figure 2). The SoaML concepts: Collaboration and CollaborationUse are introduced into the QoS metamodel. This metamodel is useful for describing and specifying security policies. The benefit of this QoS metamodel is that the quality attributes can be managed easily. However, the QoS model is just for quality of service specification, but it does not represent the implementation aspect of quality attributes. In this paper, we propose new concepts that can be used to implement the quality attributes requirements. Two typical viewpoints of security aspect in SOA system are information based viewpoint [7] and service based viewpoint [8]. SOA is an architectural approach to building systems by using a set of services. These services interact with each other by sending messages. The most significant aspect of security in such systems
is the information security. The information has two states: stored information and information in transmission.
Figure 2. QoS Metamodel Security on stored and in transmission information has different concerns. Stored information view focuses on access security that includes service requests authentication and authorization. Information in transmission view focus on message level security that includes message authentication and message integration. But the security attributes such as maintainability, auditabilityand reliability cannot be represented by information security. Hence, information security is a view of SOA security. Han et al. [8] analyze SOA based security from two views: individual service and services composition. Individual service and service composition have different responsibility to SOA security. These two views separate on the forms of service existence. And different forms of service existence have different security requirements. Service based viewpoint defines the domain at service level, which is easy to capture, adapt and satisfy the security requirements of service consumers. The most important security attributes for this viewpoint are authentication and authorization of services, maintainability and service level reliability. Through a review of the previous work, information state viewpoint and service based viewpoint are apparently not enough for SOA security. Because, the two viewpoints did not include the security attributes trust, auditability and system level reliability. So in our approach, we combine the two viewpoints and add a new viewpoint organization viewpoint, which will take charge of security attributes trust, auditability and system level reliability.
3. PROPOSED METAMODEL This section describes some of the SOA security requirements, the metamodeling process, and the proposed Security SoaML metamodel. The SOA security requirements are gathered from literature and grouped into three different views: information view, service view, and organization view. In order to extend the SoaML for introducing security constructs, we have followed the refinement process suggested in [9].
3.1 The SOA Security Requirements Quality attributes such as security are usually vaguely defined. It is important to explicitly and accurately elicit, specify, and model quality attributes in order to ensure their achievement. Like others, our approach emphasizes the need of modeling quality attributes from different viewpoints such as information view, service view, and organization view. Each of these views has
different security goals that need to be analyzed separately. Following are some of the SOA security requirements gathered from the relevant literature [7][10][11][8].
3.1.3 Organization SR1. Services in the system including their definitions must be authenticated [11];
3.1.1 Information Information has two states: Stored information and information in transmission. The stored information contains security policies, interaction records, service definitions, and information needed by service operations. Some information is stored internally in a service, and some information is stored externally of a service (like middleware) [8].
SR2. Services in the system must be authorized;
Security Requirements (SR) for stored information: SR1. Service requests must be authenticated [7]; SR2. Service consumer is authorized to a service (Access control and service consumer authorization); SR3. The operation of a service consumer must be controlled (The privilege of the service consumers and Information protection); SR4. The Service provided information must be authenticated; SR5. The content/format of the message is valid (Information verification); Security Requirements (SR) for information in transmission: SR6. The content of the exchanged message should be protected (Confidentiality of a message in transmission); SR7. An information receiver (Service consumer and provider) must verify that the content of the received messages have not been modified during transmission. (Integrity of the message) [7]; SR8. The content of the received message must be authenticated (Authentication of the message);
SR3. Service Level Agreement (SLA) must be specified clearly; These three requirements can ease to build trust between services. SR4. All interactions between services should be logged in order to identify potential attacks, trace the attackers, gather information of abnormal activities, and recover failed interactions. (Auditability); SR5. The ability of security actions: recover action, detect action, and prevent action.
3.2 Extending SoaML for Security We have extended SoaML for security by following a process derived from the method engineer refinement process presented in [9]. We selected this process called refinement for guiding our effort to extend SoaML because we needed to refine the SoaML metamodel in order to introduce the security aspect of SOA (Figure 3). We chose SoaML as the basic concept to be extended. It has been mentioned that SoaML is a modelling language for SOA; however, it is predominantly focused on modelling functional aspects of a system. In order to model non-functional aspects, the QoS UML concepts need to be added to SoaML. For modelling security attributes, it is necessary to introduce some new concepts into SoaML. After determining the concepts, the relationships which represent how the concepts work together should be defined specifically. Then the SoaML is refined by extending and combining new concepts.
SR9. The information sender and information receiver must be authenticated; SR10. The ability of security actions: detect action, prevent action, and recover action; 3.1.2 Service Security Requirements (SR) for a Single Service SR1. The security policies can be defined clearly. The policies can describe the kinds of contexts under which different operations provided by service can be executed; so security policy is constraint to the service operations [11]; SR2. The policies should be externally published so a service consumer can choose an appropriate service based on security policies specifications; SR3. Service must satisfy security request of service consumer; SR4. If a service‟s consumers are uncertain, the security policies can be effectively changed; SR5. Service definition should be defined clearly; SR6. The ability of security actions: detect action, prevention action, and recover action. Security Requirements (SR) for service composition SR7. The access restriction to the composed service is at least the sum of the restrictions of all underlying operations it is composed of and that are invoked compulsorily. This allows checking authorization at an earlier stage, thereby limiting unnecessary calls ending in rollback operations if particular permissions for invoked basic service operations are missing.
Figure 3. SoaML4Security Metamodel development process (adapted from Hug, C., Front, A., Rieu, D. and Sellers B., H., 2009)
3.3 SoaML4Security MetaModel The Metamodel is introduced in “Top Down” way. The organization security metamodel is used to model high level security architecture to represent the security service collaboration and participating architecture. Then the service security metamodel provides a way to represent the details of the high level security service collaboration, which can compose many sub-security services. In the service security level, the metamodel provides a way to implement the security attributes. Finally, the information security metamodel provides guidelines for modelling and implementing information security strategy decisions. 3.3.1 Organization Security Metamodel The Organization Security Metamodel is shown in Figure 4. The metamodel incorporates the concepts from SoaML metamodel, Security UML Metamodel [12] and SOA metamodel [7].
Organization consists of more than one participant and is also a participant; hence, an organization possesses all the features of participants. Role: Each Participant can have more than one role. Each role has certain permissions, which specifies the authorization privileges. The authorization management of participants is based on role. ParticipantDefinition: This component specifies the participant‟s basic information. We adopt the definitions in Semantic Web Services Framework (SWSF) [13] which provides the definition of service. The ParticipantDefinition information is public to external participants. So a consumer participant chooses a service participant based on the information defined in ParticipantDefinition. SecurityArchitecture extends ServiceArchitecture. It represents the internal participants of a component that has the responsibility of securing this component.
Figure 5. Service Security Metamodel SecurityAttribute extends QoS concept QoSCharacteristic. The SecurityAttributes in this paper includes Authentication, Authorization, Integrity, Confidentiality, Auditability, Maintainability, Reliability and Trust. New security attributes can easily be added to the model. QoSProperty is used to implement QoSCharacteristic. SecurityProperty is used to implement SecurityAttribute extends QoS Property. The SecurityProperties includes Error management, Simplicity, Access control, Defensein depth and Federation. 3.3.3 Information security metamodel Figure 6 shows the information security metamodel. The concepts in blue colour come from SoaML. The white colour concepts are the new security concepts added to SoaML. The concepts Policy and Permission originate from Access control model [14] which ensures the authentication and authorization.
Figure 4. Organization Security Metamodel 3.3.2 Service Security Metamodel Figure 5 shows the Service Security Metamodel, which incorporates some concepts from QoS model language and SoaML and adds new concepts into SoaML for security. QoSServiceInterface defines the interface to a QoSRequest and a QoSService extends SoaML concept ServiceInterface. The QoSServicInterfaces are used to specify the operations involved in a QoSService interaction. It is also used to specify the order in which those QoS operation are executed. The requestor makesQoS request through QoSServiceInterface and the provider provides QoS service through QoSServiceInterface QoSRequest is a request point which is used by the QoS service consumer. QoSService is a service point which is used by the QoS service provider who must provide the required quality of service requested by QoSRequest. ServiceConstraint represents pre-conditions or postconditions on security operations which is represented in QoSProperty. Security is a QoSCategory, which introduces a set of non-functional attributes categories such as performance, security, and availability.
In our case, Policy is specific to security Policy which represents a set of security constraints and requirements. In information security, these security constraints and requirements are the composition of all permissions and a set of interaction rules of a security object. The ServiceChannel contains a set of Policies, which set the interaction rules when the ServiceChannel connect two participants. The information transmission should also follow the Policies defined in ServiceChannel.
Figure 6. Information security Metamodel
Table 1: Authentication Scenario Security Attribute Name: Authentication Source
Candidate, Employer, Verification Officer, Education Institute, Referee, Bank Credit Card verification service
Stimulus
Tries to access QVS system, modify information, interact with external services( e.g. provide authentication information of candidate to the system, provide authentication credit card information of users to system)
Artifact
QVS services, Stored and Transmitted Information, and QVS system
Environment
Either online or offline, connected or disconnected, firewalled or open
Response Response Measure
Authenticates user; Allows the authenticated users access to data, services or QVS system. Denies unauthenticated users access to data, services or QVS system. Informs user when failed in access data, services and QVS system Probability of detecting wicked access system; Extent to which legitimate access denied
Permission defines one service usage context. The Permission is always used in role based access control. In this metamodel, the permission is also used for controlling the operations on information. That means the Permission is the constraints on the InformationOperation and specifies what can a participant do based on a specific role which controls the participant's scope of operations. SecurityCharacteristic extendsQoSCharacteristic which has been derived from QoS UML model. It defines a set of security attributes such as authentication, authorization, integration, trust. SecurityCapability extend SoaML‟s ServiceCapability. A SecurityCapability specifies a capability to achieve a security attribute. For reusability, the security attribute is implemented in an independent component. The component contains one or more than one security properties. Security properties are a collection of security elements that are used to implement security attributes. Policies as constraints decide which properties should execute. SecurityCapability provide a way to discover and document the security attribute component and specify its capabilities using operations or realized interfaces. Filter: In this proposed metamodel, a ServiceChannel can contain Filters to specify the semantics of information transmission and message processing. The Filter can connect to Endpoint, so the Filter is the first and the last door of information to get into and get out of ServiceChannel. When a message is sent from an Endpoint, the Filter checks the validation of the message and the identity of the message sender. The valid message can go through the Filter and get into ServiceChannel. At the end of ServiceChannel, another Filter checks the validation of the message again to ensure the message is not modified in transmission. MessageFilter checks an incoming message against the message schema, criteria specified in policy, and forwards only valid message. MessageFilter extends the Filter and validates the message content. IdentityValidator validates the identity of a message sender (Participant) against the authentication specified in policy and forwards only valid Participant; hence, it ensures participants‟ authentication. Logger records all the information transmission and helps to identify potential attacks and modifications, trace the attackers, gather information of abnormal activities, and recover failed transmission. The
ServiceChannel can contain a Logger to ensure the auditability of the information transmission. StoredInformationrepresents security policies, interaction records, service definitions, and information needed by service operations. The MessageTypes represent “pure data” that may not depend on the environment, location or information system. StoredInformation extends the SoaML concept MessageType and it is also pure data centric. InformationOperation can be Read, Delete, and Update. Permission is a constraint on the InformationOperation. The Permission assigns different operation authorization to different participants.
4. An Illustrated Example In this section, we demonstrate the use of SoaML4Security by modelling security requirements of a service-based application called Qualification Verification System (QVS), which is a real industrial application to be redesigned and migrated to SOA based platform. QVS supports the recruitment process by providing services to verify the qualification information, referees, and work history provided by job applicants. A potential employer can use this system to get verified records of applicants. Each type of services required by applicants and employers incurs a service fee which should be paid by Credit Card. The information of Credit Card will be verified by a Bank.
Figure 7. QVS Service Architecture Figure 7 shows the QVS service architecture, which is defined as community collaboration. The QVS service architecture can show the roles of participants and services at a high level and contextual view. This community collaboration includes five primary roles: Candidate, Bank, Employer, VerificationOfficer and Verifier. The
Figure 8. QVS UseCase Diagram VerificationOfficer acts as an agent in this community who verifies the qualification information of applicants, and provides the verification result to potential employer. The VerificationOfficer communicates with other participants through four B2B services: request verification service, credit card service, enquire authenticity service and verify outstanding request service. In our case, QVS provides three types of verification information: qualification, referees and work history. So three participants: education institute, referee and employer (i.e., past) play the role of verifier. Figure 8 shows the detailed Use Case of QVS. Because security is the main purpose to model, so the data records and event records are shown as use cases in this Use Case diagram. Based on this Use Case diagram, we introduce the QVS system from three facets: Information, Event and interaction with external participants. Information: The information could be provided by external participants such as candidates, employers, referees and could be generated by QVS system such as informed information. This information should be protected from maliciously actions. Event: All events in the system need to be recorded and stored. These records are used to recover crashed events. When a new employer registers to the system, the information about employer must be verified by a verification officer. The successful or unsuccessful login event of users should be recorded. Interaction with External Participants: The external participants of QVS are Candidate, Employer, Bank, Education institute and Referees. The identity of employer and referees must be verified by QVS as the authenticated employer can view the information about candidates and verified referees who can send recommendation letter for applicants. An employer needs a permission to view the verification information about applicants and employer hopes the recommendation letter they receive from referees who have qualification to write that letter. The employers should trust the qualification verification information provided by Education institute such as universities. Bank is the third party used for payment settlements. The bank needs to be trusted about credit card security and the correctness of payment.
4.1 Security Scenarios for QVS We have formatted the security scenario for QVS using the six elements framework reported in [15] and these scenarios have been categorized by security attributes. Scenarios are widely used in requirements elicitation, interface engineering and design alternatives comparing [16]. Moreover, the scenarios as a technique are usually used by programmers and designers to understand a system. The six elements scenario description framework deals with a question that under a certain environment how the system response to a particular stimulus. The security scenario contains six parts: Source, Stimulus, Artifact, Response and Response Measure. From the six parts, the security is specified: who is the attacker, when they attacked, where they attacked, what responses the system made and how to measure the response. However, every scenario does not need to have all the six parts. The six elements framework helps establish concrete, complete and measurable security scenarios. We give an example of authentication scenario in Table in the Appendix.
4.2 Using SoaML4Security for QVS The QVS security architecture is built in “top down” method. First, the organization security provides a high level view of secure interaction between participants; then we deal with the service level security. For each service, the architecture should provide appropriate security strategy. Finally, the security architecture is detailed into data level. The information security view represents the information security strategy decision. The architecture is modeled by Objecteering SOA modeling tool [17]. The tool does not allow a user to define new stereotype. The new stereotypes for the extended metamodel cannot be shown in the models. To deal with this problem, the stereotype is represented by tagged value and the display format is {design (stereotype)}. 4.2.1 Organization Security The organization has composition relationship with other three components: Participant, Resource and Logger. The metamodel is shown in figure 9. The Role and Permission are supposed to protect the system from unexpected actions. Each participant has a role which specifies a certain groups of permissions which limits
the privilege of a participant. Logger records all the interactions between participants. These records are stored in Resource as resources which help to identify potential attacks, trace the attackers, gather information of abnormal activities, and recover failed interactions. The organization architecture defines the basic role protection and basic resources for security actions.
Figure 9. Organization Part Metamodel 4.2.2 Service Security For the service level security, this section uses the “Login Service” as an example to show the process of designing security contract (QoSContract type). Login security service is a subSecurityService of account security service.According to the Service Security metamodel, the Service Contract has a composition relationship with policy and QoS Contract extends Service Contract so the QoS Contract can compose policies. The figure 10 shows the Login Service Security Policy within Login Service Security Collaboration. The Login Service Security Policy composes Authentication, Auditability and Authorization which is shown in figure 11. The stereotype of Authentication, Auditability and Authorization are QoSCharacteristic. The QoSCharacteristic is a type of Policy. The metamodel shows thatQoSCharacteristic extends Policy, which composes QoSCharacteristics that means the QoSCharacteristics can be used by any combination and is easy to extend, use and reuse.
Figure 11. Login Service Security Policy In the partial service security metamodel shown in figure 12.a, we define a new concept called QoSServiceInterface, which extends ServiceInterface.QoS service interface has the same feature as service interface. It is used to specify the rules for the interaction between QoS requester and QoSprovider. The login service security policy (see figure 11) composes three security attributes: Authentication, Auditability and Authorization.
Figure 12.a. QoSServiceInterface and Participant The QoSServiceInterface has two parts: one part can realize the interface defining the capability, and another part uses the interface defining the response (Figure 12.b.). In this case, the individual QoSServiceInterface can realize IndividualInterface and use AuthenticatorInterface. The Authenticator QoSServiceInterface can realize AuthenticatorInterface and usesIndividualInterface. The individual triggers Authentication security service by using function requestAuthentication().
Figure 12.b. Authentication 4.2.3 Information security We give an example about Credit Card Information Security to explain how to use the information security metamodel.
Figure 10. Login Service Security
Figure 13. Information Security Policy The information security policy metamodel which is a partial metamodel of information security is shown in figure 13. Policy
composes more than one „Permission‟s and which can be grouped into different SecurityAttributes. SecurityAttribute extends the QoS concept QoSCharacteristic. SecurityCapability which extends SoaML concept ServiceCapability is used to expose and compose the capability of the security components.
6. REFERENCES 1. Service oriented architecture Modeling Language (SoaML) – Specification for the UML Profile and Metamodel for Services (UPMS). [Online] 2008. http://www.omg.org/docs/ad/08-0804.pdf.
Figure 14 shows the CreditCard Information Transmission Policy design. CreditCard information transmissionPermission is an internal class of CreditCard Information Transmission Policy component. The permissions are grouped into Authorization permission, Integrity permission and Auditability permission. CreditCard Information Transmission Policy associates to Credit Card Information SecurityCapability which composes other three SecurityCapability: Integrity SecurityCapability, Authentication SecurityCapability and Auditability SecurityCapability.
2. UML Profile for Modelling Quality of Service and Fault Tolerance Characteristics and Mechanisms. s.l. : OMG , 2004. ptc/2004-06-01.
5. CONCLUSIONS AND FUTURE WORK This paper has described an approach to extend SoaML metamodel to incorporate security constructs for supporting model driven development of service-oriented application. Our work leverages the concepts of QoS for modeling quality attributes of SOA based system. The advantage of introducing QoS concepts into SOA is easy to manage the quality attributes categories. The quality attributes are designed into service collaboration, and then the policies of the quality attributes can be designed into Service Contract. In this sense, service consumer can choose a property service based on the specification of quality attributes. Then service consumer can not only benefit from the functional aspect of a service, but can also achieve the desired non-functional requirements.
5. Quality Attributes and Service-Oriented Architectures. O‟Brien, L., Bass, L. and Merson, P. s.l. : Systems Development in SOA Environments, SDSOA '07: ICSE Workshops, 2007.
3. Non-Functional Property Driven Service Governance: Performance Implications. Liu, Y., Zhu L., Bass, L., Gorton, I., and Staples, M. s.l. : ICSOC, 2007. LNCS 4907, pp. 45-55. 4. Metamodeling. Wikipedia. [Online] [Citeret: 20. July 2009.] http://en.wikipedia.org/wiki/Metamodeling.
6. Crnkovic, I., Lau, K., K. and Mirandola, R. (2008) 'SOA and Quality Assurance', Euromicro Conference Software Engineering and Advanced Applications. 7. Delessy, N., A., and Fernandez, E., A. (2008) 'A Pattern-Driven Security Process for SOA Applications', Third International Conference on Availability, Reliability and Security, 416-421. 8. Han, J., Kowalczyk, R. and Khan, K., M. (2006) 'SecurityOriented Service Composition and Evolution', Software Engineering Conference, 71-78. 9. Hug, C., Front, A., Rieu, D. and Sellers B., H., (2009) „A Method to build information systems engineering process metamodels‟, Journal of Systems and Software, Volume 82, Issue 10, 1730-1742. 10. Lang, U. and Schreiner, R. (2007) 'Model Driven Security for Agile SOA-Style Environments', Securing Electronic Business Processes, Vieweg (2007), 147-156. 11. Mouelhi, T., Fleurey, F., and Baudry B. (2008) 'A Generic Metamodel For Security Policies Mutation', IEEE International Conference on Software Testing Verification and Validation Workshop (ICSTW'08).
Figure 14. Credit Card Information Security Policy The SoaML4Security metamodel not only facilitates the security policy management but also supports the security attributes implementation. The metamodel is separated into three views: Information view, Service view and Organization view. Hence, the security architecture can be designed easily and completely. One of the limitations of the proposed metamodel that it cannot implement the security service contract negotiation, which means that after the security policies specified, it cannot be dynamically changed to meet the consumer's request. Besides, the tradeoff between security and other quality attributes have not been covered in this paper. The viewpoints can also be extended at an enterprise level using a framework like Zachman´s framework. Our future work intends to look into these directions.
12. Basin, D., Doser, J., Clavel, M. And Egea, M. (2007) 'A Metamodel-Baed Approach for Analyzing Security-Design Models', MoDELS 2007, LNCS 4735, 420–435. 13. Toma, I. and Foxvog, D. (2006) 'Non-Functional Properties in Web Service', WSMO Working Draft, available: http://www.wsmo.org/TR/d28/d28.4/v0.1/20060616/ 14. Torry Harris Business Solutions (2009) 'Migration and Security in SOA', White Paper, available: http://systemsintegration.searchsoa.com/document;5133778/soaabstract.htm [accessed 17 Aug 2009] 15. Bass, L., Clements, P. and Kazman, R. (2003) 'Software Architecture in Practice Second Edition', Addison Wesley 16. Kazman, R., Abowd, G., Bass, L. and Clements, P. (1996) 'Scenario-Based Analysis of Software Architecture', IEEE Software, Nov. 1996 17. Objecteering model-driven modeling and engineering tool, http://www.objecteering.com/index.phpsa
