SecureSOA – Modelling Security Requirements forService-oriented Architectures

Michael Menzel, Christoph Meinel

Hasso-Plattner-Institute,Prof.-Dr.-Helmert-Str. 2-314482 Potsdam, Germany

{michael.menzel, meinel}@hpi.uni-potsdam.de

Abstract

Service-oriented Architectures (SOA) facilitate theprovision and orchestration of business services to en-able a faster adoption to changing business demands.Web Services provide a technical foundation to real-ize this paradigm and support a variety of different se-curity mechanisms and approaches. Security require-ments are codified in Web Service policies that controlthe service’s behavior in terms of secure interactionswith other participants in an SOA. To facilitate andsimplify the generation of enforceable security policies,we foster a model-driven approach based on the mod-elling of security requirements in system design models.This paper introduces our security design language Se-cureSOA that enables the definition of these securityrequirements. We present the abstract syntax and no-tion of SecureSOA and describe a schema to integrateSecureSOA in any system design language for service-based systems. Moreover, we will demonstrate the inte-gration of SecureSOA in Fundamental Modelling Con-cept (FMC) Block Diagrams.

1 Introduction

IT-infrastructures have evolved into distributed andloosely coupled service-based systems that are capableto expose company’s assets and resources as businessservices. To implement this paradigm, the Web Servicespecification provide a technical foundation based onXML-messaging. In addition, Web Services facilitatethe usage of different security patterns, mechanismsand algorithms to secure the interaction between theparticipants in an Service-oriented Architecture.

Security policies for SOA (e.g. WS-Policy and WS-

SecurityPolicy) are used to state these security require-ments on a technical layer concerning the usage ofspecifications such as WS-Security. These policies en-able services to communicate requirements to its ser-vice consumers, for example, to inform about requiredidentity information, trusted parties or required mech-anisms to secure exchanged information.

To enable a simplified generation of security policies,we foster a model-driven approach that integrates se-curity intentions in SOA system models. SOA systemmodels provide an abstract view on different aspectssuch as participants, information, and processes. Theintegration of security intentions enables a modeller tostate basic requirements on a technically independentlevel. For instance, confidentiality requirements or re-quired identity information can be annotated.

Modelling security has been a research topic in re-cent years. Jurjens introduced the UMLsec extension[1] to express and verify security aspects within UML-diagrams. However, to perform such a formal verifica-tion, all security-related aspects such as cryptographicdata must be specified in the system model. This wouldbe a suitable approach for security experts, but it tendto be difficult to understand without a strong securitybackground.

Other approaches [2, 3] proposed enhancements forprocess models to express security requirements, but donot describe a schema to integrate these requirementsin arbitrary modelling languages. Moreover, these ap-proaches do not provide a meta-model that is capableto represent interacting participants in a Service-basedsystem. To enable an automated generation of secu-rity policies for SOA, the roles and relation of theseparticipants must be defined in the model as well.

In [4] Basin and Lodderstedt introduce SecureUMLthat provides a security design language to describe

1

role-based access control and authorisation constraints.In summary, related approaches have been focused

on the modelling of authorisation requirements or thespecification of security requirements in the scope ofbusiness processes and do not support the generationof security policies. To support our model-driven ap-proach, we present in this paper:

• An adaption of the schema introduced by Basin etal. [4] to define new security design languages forservice-based systems.

• The abstract syntax and notion of our securitymodelling language SecureSOA used to express se-curity intentions.

• The integration of SecureSOA in FundamentalModelling Concept (FMC) Block Diagrams to en-able the annotation of security requirements insystem models.

Our security modelling language SecureSOA consti-tutes the foundation of our model-driven approach. Se-curity intentions modelled in a language based on Se-cureSOA are translated to our meta-model for securitypolicies in SOA that has been introduced in [5]. Finally,the security requirements defined in the meta-modelare used to generate enforceable WS-SecurityPolicies.

The structure of this paper is as follows. In Sec-tion 2 we will introduces our concept to enhance designmodelling languages with security intentions. Section3 presents the syntax of our security design languageSecureSOA to model these intentions. In the next sec-tion, a SecureSOA dialect based on FMC is introduced.Section 5 presents a use case that is modelled usingthis security design language. Our model-driven ap-proach for SOA is outlined in the next Section. Section7 presents related work, while Section 8 concludes thepaper.

2 Modelling Security Intentions forSOA

Various modelling languages and dialects have beendefined that can be used to model different aspects inan SOA. For instance, the system structure can be visu-alised in UML or FMC, while the processes executed bythis system can be modelled with BPMN. Each mod-elling language provides a specific view on a particularaspect of the system that can be used to annotate se-curity intentions. To aggregate and enforce intentionsfrom different types of modelling lanugages, securityintentions must be defined consistently and indepen-dent from any modelling language. In this sections we

discuss strategies to integrate security intentions intomodelling languages and outline the steps of our ap-proach.

2.1 Enhancing modelling languages

To integrate security intentions in system design lan-guages, an enhancement of these languages is required.In general, three approaches can be distinguished toimplement such an enhancement:

1. Light-weight extensions – The easiest way to en-hance a particular system design language is theusage of extension points provided by the lan-guages itself. For instance, UML provides stereo-types and tags to extend UML modelling elements.However, the visualisation of complicated securityrequirements might get confusing. Moreover, notall modelling languages define extension points toenhance modelling elements.

2. Heavy-weight extensions – Another approach toenhance modelling languages is based on the ex-tension of its meta-model. For example, this ap-proach is used by Rodrıguez to define his securityextensions for BPMN and UML [2] process mod-els. The fact that the definition and integration ofsecurity requirements is done specifically for a par-ticular system design modelling language based onits meta-model is one major disadvantage of thisapproach.

3. Defining a new language – To avoid the drawbacksmentioned above, a new modelling language canbe defined. This modelling language integratessecurity elements and contain specific redefinedelements of a system design modelling language.SecureUML uses this approach to model securityrequirements as an integral part of system mod-els. Therefore, Basin and Lodderstedt describeda generic approach to create a new security de-sign languages by integrating security modelinglanguages into system design modelling languagesas described in [4].

2.2 Defining Modelling Design Languages

The advantage of the schema described by Basin andLodderstedt is its flexibility. A security modelling lan-guage can be defined once with certain extension pointsand can then be integrated into different design mod-elling languages for service-based systems. The result-ing language is called a modelling dialect. Moreover, a

2

formal semantic can be defined for the security mod-elling language that enables the verification of the re-quirements modelled in any dialect. We have adoptedthis approach as shown in Figure 1.

Figure 1. Schema for Constructing SecurityDesign Languages

The schema consists of the following parts:

1. A security modelling language is used to expresssecurity requirements for a specific purpose. Wehave defined SecureSOA that enables a modellingof security intentions for services-based systems.

2. The structure of a system is described using a sys-tem design modelling languages. While differenttypes of modelling languages can be used, our ap-proach is based on FMC Block diagrams that areused to visualise system architectures.

3. Both languages are integrated by merging theirvocabulary using the extension points of the secu-rity modelling language. The resulting language isa called a dialect.

2.3 Merging Security and System Designlanguages

In SecureSOA, extension points are formalised enti-ties that relate to security intentions. These extensionpoints can be mapped to entities in any system designmodel.

For example, we formalise participants in an SOAsuch as services as objects that participate in an in-teraction by exchanging information. FMC visualisessystem architectures that are composed of agents com-municating over a channel. Therefore, an object is anextention point and can be mapped to an agent.

As stated by Lodderstedt in [6], there is no uni-versal approach to perform an integration of arbitrarysecurity and design modelling languages. The inte-gration technique depends on the structure of the se-

curity modelling language. In the scope of Secure-SOA, we have identified three integration patterns thatare listed in Table 1. The definition of these pat-terns is based on the classes and their relationshipsin the meta-models of the security and the system de-sign languages. We denote the set of classes in theSecureSOA meta-model as s = {s1, . . . , sn1}, classesin the meta-model of the security design language asm = {m1, . . . ,mn2} and classes in the meta-model ofthe dialect as d = {d1, . . . , dn3}.

3 SecureSOA - a Security Design Lan-guage for SOA

SecureSOA enables a modelling of security inten-tions for service-based systems and is defined by aMOF-based meta-model (abstract syntax). In addi-tion, we will introduce the notion of these elements(concrete Syntax) as UML profiles. Finally, the def-inition of the formal semantics of SecureSOA will beoutlined in this Section.

3.1 SecureSOA Abstract Syntax

The SecureSOA meta-model [5] specifies the ele-ments of this security language and consist of two parts.The meta-model for SOA introduces the basic entitiesin our model and their relationships to describe interac-tions in a Service-oriented Architecture. Based on thismodel, a model for security intentions and annotationsis provided as well.

3.1.1 A Meta-Model for SOA

Figure 2. The Security Base Model

As introduced in [7], one of the basic entities in ourmodel is an object that consists of a set of attributes,participates in an interaction, and has trust relation-ships, see Figure 2. In addition, each interaction alsoinvolve the exchange of information. For instance inthe scope of Web Services, an object could be a WebService client or a Web Service itself. Therefore, wesubclassify objects into service, client and sts.

3

1) Subclass extension pointsThe easiest way to perform the integration is to map a class mj in the design modellinglanguage to its corresponding extension point si in SecureSOA that represents an abstractionof this class. This dependency can be easily represented as an inheritance relationship inthe dialect between the classes si and mj .

2) Enhance the dialect with new classesIn this case, a class si in SecureSOA can be mapped to a class mj in the design modellinglanguage as described by pattern 1. In addition, this class is inherited by a class si′ ofSecureSOA that models a specific aspect of service-based systems. However, it is unlikelyto find a class in a general purpose modelling language that corresponds to this specialisedclass si′ , although the abstract parent class si has been mapped. To associate the extensionpoint si′ with the design modelling language, it is necessary enhance the dialect with a newclass dl that inherits the class si′ and mj .

3) Define associations and OCL constraintsHowever, there might not be straight mapping for each extension point of SecureSOA, sincecertain aspects might be modelled on a different level of abstraction in both languages.In this case, a class si has to be mapped to multiple classes mj and mk in the otherlanguage. To integrate these classes into the dialect, association have to be defined betweenthe corresponding classes. OCL constraints can be used to capture additional semantics ofthese dependencies.

Table 1. Schemas for Creating the Modelling Dialect

To enable a detailed description of Web Service mes-saging, we model transferred information as data trans-fer objects as introduced by Fowler in [8]. In [5] we haveshown the usage of this structure to describe SOAPmessaging. A data transfer object has a target and anissuer. This reflects that a data transfer object can besend over several objects acting as intermediaries.

The classes defined in the scope of this SOA meta-model are the extensions points of SecureSOA as de-scribed in Section 2.2.

3.1.2 Modelling Security Intentions

Based on the SOA meta-model that has already beendescribed in previous work [5], we have specified an en-hancement of this model to express security intentionsand annotations.

Security intentions are defined specifically for one se-curity aspect in terms of service security and are relatedto one or more security goal. We have defined the fol-lowing set of security intentions: User Authentication,Non-Repudiation, Identity Provisioning, Data Authen-ticity, Data Confidentiality, and Trust. Data Confi-dentiality, for instance, requires the security goal con-fidentiality for a particular piece of information, whileidentity provisioning states that the trustworthy iden-

tification and authentication of a user at a particularobject is required. However, SecureSOA is not limitedto this constraints and supports custom enhancementsby adding additional security intentions.

Figure 3. Modelling Security Intentions

As shown in Figure 3, each security intention is re-lated to a security profile. The fundamental idea isto hide technical details at the modelling layer. Themodeller should not be bothered with details such assecurity algorithms and mechanisms that are used toenforce this intention. This set of information is prede-fined in a security profile and is then referenced by thesecurity intention. Moreover, security intentions staterequirements for a specific subject that is either an ob-ject or a data transfer object. Therefore, each security

4

intention has a intention subject. Object intentions re-fer to an object, while information intentions refer toan data transfer object.

While security intentions represent requirements, weuse security annotations to represent security-relatedcapabilities. For example, annotations could expressidentity claims that are supported by an identityprovider. Annotations are defined similar to the se-curity intention structure as shown in Figure 3.

3.2 SecureSOA Concrete Syntax

The concrete syntax specifies the visualisation of theelement that are defined by the abstract syntax. Sincethe extension points of the SecureSOA meta-model(e.g. objects or interactions) are mapped to classesin the design modelling language, their notion is basedon this language. Therefore, we just have to define thenotion of security intentions and annotations.

In general, there are two possibilities to define a con-crete syntax (notion) for these elements. The first op-tion is to express them as a property of the subjectof the element. Another option to visualise security re-quirements is the definition of artifacts for each elementthat can be used to annotate the element’s subject. Wehave chosen this approach to define the concrete syntaxof security intentions specified by SecureSOA.

Our notion for security inentions is based on a UMLconcrete syntax using UML classes and stereotypes.Each intention is visualised as an UML class that isconnected to the intention’s subject using an UML as-sociation. The mapping between SecureSOA intentionsand UML stereotypes is listed in Table 2. The notionfor security annotations is specified correspondingly.

UML Stereotype Symbol<< User Authentication >>

<< Non-Repudiation >>

<< Identity Provisioning >>

<< Data Authenticity >>

<< Data Confidentiality >>

<< Trust >>

Table 2. SecureSOA Concrete Syntax

3.3 SecureSOA Formal Semantic

We can formalize our SecureSOA meta-model asa relational model (based on sorts and relations) asdescribed by Lodderstedt [6]. This formalisation fa-cilitates the verification of the transformation in our

model-driven approach and will be outlined briefly:Classes and associations in the SecureSOA meta-modelare mapped to a set ci in a model m that contains anentry for each instance of a specific class or associa-tion. Each intention defines requirements concerningthe exchange of information in a system m

′that repre-

sents an secured instance of m. Therefore, the formalsemantic of each security intention can be specified bydefining an implication on the models m and m

′. For

example, if the security intention data authenticity re-lates to a data transfer object in the model m, then itwill imply that this data transfer object must containa signature in the model m

′.

4 A SecureSOA dialect based on FMC

SecureSOA offers the possibility to express securityintentions in various modelling languages. We havechosen FMC Compositional Structure Diagrams (BlockDiagrams) as a system design modelling language, sinceFMC offers a suitable foundation to describe an SOAon a technical layer in terms of involved participantsand their communication channels.

4.1 Fundamental Modeling Concepts

Fundamental Modeling Concepts (FMC) providesan approach to describe software systems. It can beused to model the structure of a system, processes in asystem, and value domains of a system.

FMC Compositional Structure Diagrams (alsoknown as FMC Block Diagrams) depict the staticstructure of a system and the relationships betweensystem components. This diagram type distinguishesbetween active and passive components. Agents areactive system components that are capable to commu-nicate via channels and to perform activities in the sys-tem. Channels and storages are passive componentsused to transmit or store information.

Figure 4. FMC Meta-Model

The FMC meta-model [9] describes the abstract syn-tax for all diagram types and is specified using FMCentity relationship diagrams. We have translated the

5

FMC meta-model to a MOF-based meta-model. Fig-ure 4 depicts the part of the meta-model that describesFMC block diagrams. Agents are connected to a stor-age or a channel that are locations and interact by per-forming read or write operations.

4.2 Merging SecureSOA and FMC

To integrate SecureSOA in FMC, the vocabulariesof both languages have to be merged and the entitiesin FMC have to be mapped to corresponding extensionpoints in SecureSOA. The meta-model of the dialect isshown in Figure 5.

Figure 5. SecureSOA-based FMC dialect

As aforementioned in Section 2.3, the easiest wayto perform the integration is to subclass elements ofSecureSOA. Object is subclassed by Agent, while In-formation is subclassed by Value. However, there is noclass in FMC that can be mapped to Service, Client,STS and Data Transfer Object. As described by ourintegration pattern 2 in Section 2.3, these extensionpoints can be mapped by adding new elements (c.f.grey coloured elements in Figure 5) to the dialect thatsubclass related elements in FMC and SecureSOA.

Finally, the SecureSOA class Interaction has to bemapped to FMC. Subclassing will not work as integra-tion technique, since interaction is not just a channel inFMC. It is composed of a channel in combination withan operation that is performed on this channel. There-fore, we defined associations and an OCL-Constraintto perform the integration as defined by pattern 3 inSection 2.3.

4.3 Defining the Concrete Syntax

The notion of the classes in the meta-model of thedialect is provided by the concrete syntax of FMC andSecureSOA. However, a notion must be defined for theelements Service Agent, STS Agent and Client Agentthat have been added to the dialect. Since these ele-ments inherit from FMC Agent, their notion is basedon the notion this class. To indicate the agent’s type(Service, Client, or STS) we enhanced the concrete syn-tax with a notion for stereotypes as defined by UML.

5 SecureSOA Modelling Example

This section illustrates the usage of SecureSOA tomodel a web shop scenario as shown in Figure 6. ThisSOA scenario has been modelled using the web-basedmodelling tool Oryx [10]. We added our security designlanguage introduced in the previous section as a stencilset to this tool.

The order scenario contains an order process, inwhich a user is requesting goods using an online storeweb application. This application invokes an composedorder service that uses two external services; a paymentand a shipping service. The payment service representsan external service which handles the payment of theorder process. In order to do so, the service needspayment information including a payment amount andcredit card information like card type, card holder, cardnumber, expiration date and a security code. The ship-ping service initiates the shipping of the goods usingthe recipients address. Note that each agent indicatesits type (Client, Service or STS) using stereotypes.

Figure 6. SecureSOA Web Shop Example

Users in this example have an account at theirtrusted bank and at the registration office, who act as

6

identity providers managing the user’s digital identity.The user can be authenticated at the identity providersto request a security token that can be used to accessa specific service.

In addition, SecureSOA is used to annotate securityintentions to various actors in this use case. The pay-ment service has established a trust relationship withthe trusted bank, while the shipping service trusts in-formation from the registration office. Therefore, themoney transfer service and the speed shipping serviceare annotated with the security intention identity pro-visioning, while the identity providers are annotatedwith the identity information that they offer. To se-cure the exchanged information, the intentions dataauthenticity and data confidentiality are used as wellin this example.

6 Model-driven Security in SOA

SecureSOA enables the annotation of system designmodels e.g. FMC block diagrams or BPMN modelswith security intentions as shown in the previous Sec-tion. This language provides the foundation for ourmodel-driven approach that enables SOA Architectsto state security intentions at the modelling layer andfacilitates a generation of enforceable security config-urations [5]. As illustrated in Figure 7, our approachconsist of three layers.

Figure 7. Model-driven Security in SOA

We use a policy meta-model to abstract from con-crete policy languages (e.g. WS-SecurityPolicy) as in-troduced in [5]. A policy in this model consists of mul-tiple security constraints that capture security require-ments on a technical layer. Information at the mod-elling layer are gathered and translated to this model.To perform this transformation, expertise knowledgemight be required to determine an appropriate strat-egy to secure services and resource, since multiple so-lutions might exists to satisfy a security goal. For ex-

ample, confidentiality can be implemented by securinga channel using SSL or by securing parts of transferredmessages. Based on the security pattern approach [11],we have defined a formalised system of security con-figuration patterns that are used to resolve securityconstraints. Finally, these constraints are transformedinto enforceable security policies based on a predefinedmapping.

7 Related Work

The domain of model-driven security in the con-text of and SOA and business processes is an emerg-ing research area. Previous work done by Rodriguezet al. [12], [2] discusses an approach to express secu-rity requirements in the context of business processes.Although they support several security requirements,they neither describe a schema to integrate these re-quirements in other modelling languages nor describea model-driven transformation.

Breu and Haffner proposed a methodology for secu-rity engineering in service-oriented Architectures [13]that is based on a model-driven approach. In partic-ular, they outlined a transformation to authorisationconstraints. Although providing a generic framework,they do not describe a mapping to WS-SecurityPolicy.

SecureUML [4] introduced by Basin et al. is a se-curity modelling language to describe role-based accesscontrol and authorisation constraints. To integrate thislanguage in different types of system design languages,they proposed an integration schema that is the foun-dation of the approach presented in this paper.

Jurjens presented UMLSec [1] to express and verifysecurity relevant information within UML-diagrams.However, the verification of security protocols and sys-tem models requires to express all security aspects atthe modelling layer. This results in models that havea certain degree of complexity and do not provide asimple, high-level notion for security intention.

Wolter [3] fosters a model-driven approach to enablea generation of XACML access control policies basedon enhanced business process models.

Jensen and Feja described a model-driven genera-tion of Web Service security policies based on the mod-elling of security requirements in business process mod-els [14].

Using security patterns, Delessy described apattern-driven process for secure SOAs [15]. An auto-mated translation to security policies is not described.

7

8 Conclusion and Future Work

System design modelling languages provide a suit-able abstract perspective to specific security goals ona more accessible level. In this paper, we presentedan approach to enhance arbitrary system design mod-els with security intentions. Our approach is basedon an universal schema that has been introduced byLodderstedt and Basin in [4] to define security designlanguages. In this paper, we introduced SecureSOA asour security modelling language to express security in-tentions related to service security and described theconcrete and abstract syntax of our language. More-over, we discussed strategies to integrate our languageinto any system design modelling language. As a proofof concept, we defined a security design language byintegrating SecureSOA in Fundamental Modeling Con-cepts Block Diagrams and added this language as astencil set to the modelling tool Oryx [10].

To illustrate the expression of security intentions inFMC, we presented an order service scenario that isused to state security intention such as trust relation-ships, identity provisioning, and confidentiality. Thespecification of security intentions is the basis for ourmodel-driven approach that addresses the difficulty togenerate security configurations for Web Service sys-tems. Altogether, our proposed modelling enhance-ment constitutes a suitable foundation to describe andimplement a model-driven transformation of abstractsecurity intentions to enforceable security configura-tions in different application domains.

In the next step, we will use the formal semantic ofSecureSOA to verify the transformation process.

References

[1] Jan Juerjens. UMLsec: Extending UML for SecureSystems Development. In UML ’02: Proceedingsof the 5th International Conference on The UnifiedModeling Language, pages 412–425, 2002.

[2] Alfonso Rodrıguez, Eduardo Fernandez-Medina,and Mario Piattini. A bpmn extension for themodeling of security requirements in business pro-cesses. IEICE Transactions, 90-D(4):745–752,2007.

[3] Christian Wolter and Andreas Schaad. Modelingof task-based authorization constraints in bpmn.In BPM, pages 64–79, 2007.

[4] David Basin, Jurgen Doser, and Torsten Lodder-stedt. Model driven security: from uml models

to access control infrastructures. ACM Transac-tions on Software Engineering and Methodology,15(1):39–91, January 2006.

[5] Michael Menzel and Christoph Meinel. A securitymeta-model for service-oriented architectures. InProc. SCC, 2009.

[6] Torsten Lodderstedt. Model driven security:from UML models to access control architectures.PhD thesis, Albert-Ludwig University of Freiberg,March 2004.

[7] Christian Wolter, Michael Menzel, and ChristophMeinel. Modelling security goals in business pro-cesses. In Proc. GI Modellierung 2008, num-ber ISBN 978-3-88579-221-5. GI LNI, Berlin, Ger-many, 1008.

[8] Martin Fowler. Patterns of Enterprise ApplicationArchitecture. Addison-Wesley Longman Publish-ing Co., Inc., Boston, MA, USA, 2003.

[9] Peter Tabeling, Rmy Apfelbacher, and StefanWappler. Fmc metamodel - the fundamental mod-eling concepts metamodel explained, September2005.

[10] Gero Decker, Hagen Overdick, and MathiasWeske. Oryx - an open modeling platform for thebpm community. In BPM, pages 382–385, 2008.

[11] Joseph Yoder and Jeffrey Barcalow. Architec-tural patterns for enabling application security. InPLoP, 1997.

[12] Alfonso Rodrıguez, Eduardo Fernandez-Medina,and Mario Piattini. Towards a uml 2.0 extensionfor the modeling of security requirements in busi-ness processes. In TrustBus, pages 51–61, 2006.

[13] Michael Hafner and Ruth Breu. SecurityEngineering for Service-oriented Architectures.Springer, October 2008.

[14] Meiko Jensen and Sven Feja. A security model-ing approach for web-service-based business pro-cesses. Engineering of Computer-Based Systems,IEEE International Conference on the, 0:340–347,2009.

[15] Nelly A. Delessy. A Pattern-driven Process forsecure Service-oriented Applications. PhD thesis,Florida Atlantic University, Boca Raton, Florida,May 2008.

8