A Semantic Model to Support Security Matching in Cloud Environments

Giuseppe Di Modica and Orazio Tomarchio

Dipartimento di Ingegneria Elettrica, Elettronica e Informatica, Universit

a di Catania,

Viale Andrea Doria 6, 95125 Catania, Italy

Keywords:

Cloud Computing, Security Policies, Semantic, Ontology.

Abstract:

Despite its technological advances, cloud computing’s adoption is not as wide as expected. Security is still

a big concern that prevents many to “cloudify” their applications and put their data in the hands of a cloud

provider. Also, interoperable scenarios fostered by SOA technologies exacerbate the security question, as cus-

tomers have to deal with multiple providers who, in their turn, must establish mutual trust relationships in order

to interoperate. In the last few years, policies are being used as a means to build networks of trustiness among

cloud providers. Standards and speciﬁcations on security management through policies have also appeared.

We argue that the main problem with this approach is that policies are expressed through syntactic languages

which, if processed by computers, show well-known limitations. We then propose an approach that leverages

on the semantic technologies to enrich security policies with semantic contents enabling machine reasoning.

The framework we developed caters for the security needs of both customers and providers, and aims at mak-

ing a smart match between what is requested and what is offered in terms of security. On the customer side,

no extra effort is required other than specifying their security policies according to well-established security

notations; an automatic procedure is charged of adding semantic content to the policies.

1 INTRODUCTION

Cloud computing has emerged as a ﬂexible, cost-

effective and proven delivery platform for providing

business services over the Internet, giving organiza-

tions the opportunity to increase their service deliv-

ery efﬁciencies, coping with dynamic business re-

quirements. However, when adopting a cloud com-

puting paradigm, an organization has to shift much

of the control over the data and operations from its

IT department to an external cloud provider. As a

result, cloud customers must establish trust relation-

ships with their providers, also being aware of how

these providers implement, deploy and manage secu-

rity on their side. The wide acceptance and adop-

tion of the SOA paradigm (Papazoglou and van den

Heuvel, 2007) has posed the basis for the realiza-

tion of world-wide and cross-domain scenarios of in-

teroperability among services. In a complex sce-

nario where the ﬁnal service delivered to the end-

user is realized by composing services run by differ-

ent providers in different administrative domains, the

end-user security is also affected by trust relationships

established among providers.

According to (Phan et al., 2008) policies will be

increasingly important to effectively support the “In-

ternet of Service” vision. Though policies have been

traditionally adopted to automate network administra-

tion tasks, in the last few years policy management

has extended its original scope. We are strongly con-

vinced they may serve very well the purpose of grant-

ing security. Multiple approaches for policy speciﬁca-

tion have been proposed that range from formal policy

languages, which can be directly processed by a com-

puter, to rule-based policy notation. Some have pro-

posed to represent policies as entries in a table con-

sisting of multiple attributes. The main approach fol-

lowed today is based on the usage of metadata and

languages for the speciﬁcation of security policies: it

permits to abstract from the low-level security mech-

anisms of the speciﬁc provider’s infrastructure. The

use of languages for the speciﬁcation of security poli-

cies also enables, on the one hand, the providers to

expose the security capabilities implemented within

their administrative domain and, on the other one, the

customers to express their security requirements.

The approach we propose calls on well-known

policy and security speciﬁcations. We deﬁne cus-

tomers’ and providers’ security requirements/capa-

bilities within policies which are compliant to well-

established speciﬁcations. What characterizes our ap-

proach is that security requirements and capabilities

427

Di Modica G. and Tomarchio O..

A Semantic Model to Support Security Matching in Cloud Environments.

DOI: 10.5220/0004375704270436

In Proceedings of the 3rd International Conference on Cloud Computing and Services Science (CLOSER-2013), pages 427-436

ISBN: 978-989-8565-52-5

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

are semantically enriched, thus enabling the employ-

ment of smarter mechanisms to make the match be-

tween what is required and offered in terms of secu-

rity, respectively on the customer and on the provider

side. The contribution of this work consists in the de-

sign of an ontology deﬁning main security concepts,

a procedure which automatically maps syntactic se-

curity requirements into semantically-enriched con-

cepts, and a matchmaker engine which is capable of

reasoning on the customer’s and the provider’s secu-

rity requirements/capabilities to derive a match level.

The rest of the paper is structured as follows. Sec-

tion 2 presents background and related work. Then in

Section 3 the overall architecture of our framework is

presented. Section 4 presents the semantic model we

designed. In particular, we thoroughly discuss the de-

veloped security ontology, provide details on the map-

ping procedure and brieﬂy recall the policy matching

algorithm. In Section 5 an example is reported to val-

idate our approach. Finally we conclude the work in

Section 6.

2 RELATED WORK

The adoption of a policy based-approach for man-

aging a system requires an appropriate language for

policy representation and modeling and the design

and development of a policy management frame-

work for policy matching and enforcement. Several

policy languages and framework have been devel-

oped following different approaches, and sometimes

have been proposed in different application domains

(Tonti et al., 2003). Among the most notably efforts

in this domain, worth citing are Ponder (Damianou

et al., 2001), a declarative object-oriented language

that supports the speciﬁcation of several types of man-

agement policies for distributed object systems, Kaos

(Uszok et al., 2003), a policy management frame-

work where concepts and policies themselves are rep-

resented using OWL, and Rei (Kagal et al., 2003), a

policy framework where OWL is extended with the

expression of relations like role-value maps, making

the language more expressive than the original OWL.

Kaos and Rei are ontology based policy languages

that, although not speciﬁcally focused on the security

domain, are able to express complex security policies:

policy matching is also supported by the advanced

reasoning capabilities these languages offer. How-

ever, when dealing with enterprises and cloud sys-

tems that adopt a service oriented paradigm, we be-

lieve that an approach compatible with existing stan-

dard for policy speciﬁcation should be followed as far

as possible.

WS-Policy (W3C, 2007) is the speciﬁcation used

in service oriented architectures to express policies.

A policy is deﬁned as a collection of alternatives and

each alternative is a collection of assertions. Asser-

tions specify characteristics that can be used for ser-

vice selection such as requirements, capabilities or

behaviors of a Web service. Policy assertions can

represent both requirements on service requestors and

capabilities of the service itself. Requirements repre-

sent a demand from service requestors to the esrvice

provider to behave in a particular way; capabilities are

the service providers promise of behaviour. Within

the WS-Policy framework, the WS-SecurityPolicy

(OASIS, 2012) speciﬁcation can be used to express

security requirements and security capabilities in the

form of policies. For example, the use of a speciﬁc

protocol to protect message integrity is a requirement

that a service can impose on requestors. On the other

hand, the adoption of a particular privacy policy when

manipulating data of a requestor is a service capabil-

ity.

Policy matching in WS-Policy works at a syntac-

tic level: it offers a domain independent mechanism

to ﬁnd alternatives that are compatible to two poli-

cies. Two alternatives are compatible if, for each as-

sertion in one alternative, there is a compatible asser-

tion in the other one. Compatibility of assertions is

deﬁned exclusively according to the equivalence of

their qnames, without any further mechanism involv-

ing either their structure or their content.

For this reason, several works in the literature (Sri-

haree et al., 2004; Verma et al., 2005; Speiser, 2010;

Zheng-qiu et al., 2009) have been trying to enhance

WS-Policy with semantic annotations. In (Sriharee

et al., 2004), WS-Policy assertions refer to policies

expressed in OWL: however that work is not focused

on policy matching, but on modeling policies as a

set of rules, which have to be evaluated using an ex-

ternal rule-based system, requiring reasoning beyond

OWL. In (Verma et al., 2005) policies represented in

WS-Policy are enhanced with semantics by using a

combination of OWL and SWRL based rules to cap-

ture domain concepts and rules. In (Speiser, 2010) a

lightweight approach to specify semantic annotations

in WS-Policy is presented: it combines the syntactic

matching with the semantic matching capability pro-

vided by OWL.

Our work, as described in next sections, carefully

extends WS-Policy by referencing concepts from a

security ontology directly in the policy assertions,

thus maintaining backward compatibility with exist-

ing tools.

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

428

Service

Provider

Service

Requestor

Matchmaker

Reasoner

Requestor

Policy

Service

Registry

Service

Policy

Security

Ontology

Service

description

Service

Policy

1. Publish

2. Find 3. Find response

4. Match request

7. Match result

5. Query

6. Query result

8. Bind

9. Interaction

Policy

Ontology

Figure 1: Overall architecture.

3 SYSTEM ARCHITECTURE

In this section we discuss the overall architecture

of the semantic security policy matching framework.

The basic architecture of the system, depicted in Fig-

ure 1, mainly follows that of classic SOA: the re-

questor, the provider and the registry keep playing

their original role in the publish-ﬁnd-bind cycle. The

novelty is the presence of the Matchmaker and the

Reasoner entities, and that of the policy-related in-

formation ﬂows.

When a service provider advertises a service, be-

sides providing the service “functional” information

in the WSDL document, it also attaches the policy as-

sociated with that service. The WS-PolicyAttachment

speciﬁcation deﬁnes how to integrate the policy infor-

mation. This information can be integrated either as

an attachment to WSDL description, or by adding it

to the UDDI registry as an extra document. When

a requestor queries the UDDI registry for a service

with given functional features, the registry also replies

with the service’s attached policy. When selecting

the service(s) that match the functional requirements,

the requestor may decide to evaluate how well the

providers’ security capabilities speciﬁed within the

retrieved services’ policies match those speciﬁed by

its own policy.

The Matchmaker is the component that the re-

questor can rely on to perform such an evaluation. It

is modelled as a web service, and receives requests

with two inputs, i.e., the policies specifying the re-

quirements and the capabilities of, respectively, the

service requestor and the service provider. The spec-

iﬁcation of both policies is done by extending WS-

Policy. Since the speciﬁcation does not impose lim-

its on the kind of allowed assertions, as already said,

for the deﬁnition of the policies we have decided to

adopt semantically enriched terms. This, of course,

will enable semantic-based procedures of policy com-

parisons.

In order to cope with existing policy speciﬁca-

tions, we developed a module able to transform a stan-

dard WS-Policy containing WS-SecurityPolicy asser-

tions into a policy expressed by using semantic con-

cepts belonging to our ontology. This way, we are

able to integrate in our framework existing systems.

The requestor’s and the provider’s policies are

compared by overlapping the requirements deﬁned in

one policy on the capabilities expressed in the other,

and vice versa. This way every possible requirement-

capability pair is assigned a match level and, in the

end, the overall match level between the requestor

and the provider is obtained. Since requirements and

capabilities are expressed in a semantic form, the

Matchmaker will invoke the Reasoner component to

perform the semantic match. To accomplish its task,

the Reasoner makes use of the Security Ontology,

which is an ontology that describes concepts from the

security domain, expressly created to let the Reasoner

evaluate the relationships among the semantic con-

cepts that populate the policies.

4 SEMANTIC MODEL

In this section the semantic model proposed by our

approach is described. An ontology was developed

to represent main concepts from the security domain.

ASemanticModeltoSupportSecurityMatchinginCloudEnvironments

429

Such ontology will be used to deﬁne concepts of se-

curity within the policies. Also, we developed a pro-

cedure which is able to automatically map security

concepts expressed in the WS-SecurityPolicy speciﬁ-

cation onto concepts of our security ontology. This

procedure enables providers and customers adopt-

ing the WS-SecurityPolicy speciﬁcation to seamlessly

use our framework. Finally, to help customers ﬁnd-

ing the providers that best suite their security require-

ments, a semantic discovery engine was developed

which is capable of reasoning on customers’ requests

and suggesting highly matching providers.

4.1 Security and Policy Ontology

To support the semantic description of security re-

quirements and capabilities two ontologies have been

deﬁned: a security ontology, that describes security

related concepts like protocol, algorithm, credential,

and a policy ontology that deﬁnes the concept of the

policy and its characterization in term of requirements

and capabilities. In the following more details about

the ontologies are provided. We point out that it is

not among the objectives of this work to provide an

exhaustive view of all concepts that populate the do-

main of security.

The policy ontology is a very short ontology that

deﬁnes the concept of policy in the context of our ar-

chitecture. A policy is nothing but a list of require-

ments and capabilities. In the OWL formalization, the

Policy Class and the related properties hasRequire-

ment and hasCapabilities have been created.

For what concerns the security ontology we takes

inspiration from the solutions proposed in literature.

As an example, the ontology proposed in (Garcia and

Felgar de Toledo, 2008), that makes explicit refer-

ences to the WS-Security’s nomenclature, addresses

the problem of security when messages are exchanged

among web services. In (Kim et al., 2005) the pro-

posed ontology covers most of the concepts of the se-

curity domain: despite it was deﬁned to address se-

curity aspects at a very high levels, there are some

constructs expressly designed to semantically anno-

tate web services. In this work we extended and re-

ﬁned a preliminary ontology (Di Modica and Tomar-

chio, 2011a), in order to adequately represent security

concepts from the WS-SecurityPolicy speciﬁcation.

A graphic overview of our proposed security on-

tology is depicted in Figure 2: the main concepts are

Objective, Protocol, Algorithm, Credential, Security

scope and Target.

A security Objective is a high level abstraction

by which we mean a particular security service of-

fered by the system. The following services can be

Figure 2: Security ontology: top level classes.

offered: authentication, authorization, conﬁdentiality,

integrity and non-repudiation.

A Protocol is a set of rules agreed by parties that

need to communicate to each other. In the context

of security a protocol makes use of tools, like algo-

rithms and credentials, in order to accomplish an ob-

jective. In Figure 3, the different protocol categories

are represented: we may distinguish encryption, sig-

nature, transport, authentication, access control and

key management protocols. Each of these categories

may contain several individuals, reﬂecting different

security protocols such as, for example, XML-Enc,

XML-Dsig, SAML, XACML, and so on.

Figure 3: The Protocol class.

An Algorithm is a procedure for solving problems

that employs a ﬁnite number of steps. In the litera-

ture several security algorithms have been proposed.

We can cite, for instance, the category of encryption

and that of authentication algorithms. For the for-

mer, another categorization can be proposed accord-

ing to the type of key used for the encryption: sym-

metric (e.g. DES, 3DES, AES) and asymmetric (e.g.

RSA). Among the authentication algorithms, instead,

we identify those that employ hash functions (e.g.

SHA, MD5) and those using MAC functions (e.g.

HMAC, CBC-MAC). We also included the categories

of Key derivation and Key wrapping algorithms. The

resulting security algorithm branch is depicted in Fig-

ure 4.

Credentials play an important role in information

systems that require authentication. Again, there are

several categories of credentials, among which we can

cite the biometric (ﬁngerprint, voice), electronic (lo-

gin, password, encrypted keys, certiﬁcates), and phys-

ical (smartcard, passport, identity card).

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

430

Figure 4: The Algorithm class.

The Security scope class allows to differentiate be-

tween security concepts related to a single host and

security in communication (like message, transport or

network level security).

Finally, the Target class allows to model the tar-

get to which the speciﬁc security mechanism is to be

applied: currently the only subclass is message parts

which models all of the elements that can be found

in a message according to the WS-Security speciﬁca-

tion.

The concepts are related to each other within the

ontology, and some properties (not shown in ﬁgures

for the sake of clarity) have been also deﬁned:

• a protocol supports one or more security objective

(hasObjective property).

• a protocol makes use of one or more security al-

gorithms (hasAlgorithm property);

• a protocol requires one or more credentials (req-

Credential property);

• a protocol may be applied to a security scope (has-

SecurityScope property);

• a protocol may protect a speciﬁc target (pro-

tectsPart property).

A policy written according to our ontology has

a standard WS-Policy structure: the wsp:Policy,

wsp:ExactlyOne and wsp:All tags are present and

have the same meaning than the standard speciﬁca-

tion. The only constraint in order to allow a correct

working of our matching algorithm is that the pol-

icy should be normalized: it has to contain only one

wsp:ExactlyOne element which, in turn, may con-

tain any number of wsp:All elements. Each element

contained in an assertion is semantically annotated

with concepts of our security ontology: in addition

it should be speciﬁed if the element represents a re-

quirement or a capability. In the following we give an

example of a policy containing only one alternative:

<wsp:Policy

...namespace definition...

<wsp:ExactlyOne>

<wsp:All>

<security:LoginProtocol rdf:ID="requirement0" >

<security:requiresCredential

rdf:resource="http://www.semanticweb.org/

ontologies/security.owl#OneTimePassword"

security:isMainCredential="false"/>

</security:LoginProtocol>

<security:Https rdf:ID="requirement1" >

<security:hasSecurityScope

rdf:resource="http://www.semanticweb.org/

ontologies/security.owl#

TransportLevelSecurity"/>

<security:requiresCredential

rdf:resource="http://www.semanticweb.org/

ontologies/security.owl#Timestamp"/>

<security:hasEncryptionAlgorithm

rdf:resource="http://www.semanticweb.org/

ontologies/security.owl#AES-256"/>

<security:hasSignatureAlgorithm

rdf:resource="http://www.semanticweb.org/

ontologies/security.owl#SHA-1"/>

</security:Https>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

The policy ﬁle starts with the wsp:Policy ele-

ment. The next element is wsp:ExactlyOne, which

contains just one wsp:All element. The policy is al-

ready normalized and contains one assertion. Two

requirements are contained in this assertion: secu-

rity:LoginProtocol, which speciﬁes a login protocol,

and security:Https, which speciﬁes a protocol for the

communication. The latter is better described by

specifying some of the used algorithms, the provided

security level and the need for a timestamp. All these

properties are speciﬁed using concepts deﬁned in the

previously described security ontology.

4.2 Policy Mapping

We developed a framework module, called Trans-

former, which is capable of transforming a policy,

written in WS-Policy and containing assertions spec-

iﬁed through the WS-SecurityPolicy, into an equiv-

alent policy whose assertions are semantic concepts

ASemanticModeltoSupportSecurityMatchinginCloudEnvironments

431

deﬁned through the above discussed security ontol-

ogy.

Let P

W SSP

be a WS-Policy compliant policy

also containing WS-SecurityPolicy assertions. The

Transformer implements a procedure that iterates on

W SSP

’s alternatives. For each iterated alternative, its

semantic equivalent is returned in the case that the

alternative is expressed in WS-SecurityPolicy; oth-

erwise, the alternative is returned unchanged. The

Transformer is fed with a Map whose keys are the ba-

sic WS-SecurityPolicy keywords and values are their

equivalent semantic concepts: the Map will be used

to semantically enrich the policy document.

In a preliminary step the Transformer parses

W SSP

and creates a tree of nodes representing the

WS-SecurityPolicy alternatives. Secondly, the tree

is visited to map combinations of alternatives onto

new “equivalent” alternatives. Finally, the original

WS-SecurityPolicy terms contained in the just cre-

ated alternatives are replaced by semantic concepts

according to the instructions provided by the previ-

ously mentioned Map. In the following, an excerpt of

that Map is reported in Table 1.

4.2.1 Mapping Examples

The Transformer’s main task, then, is to ﬁnd the cor-

respondence between WS-SecurityPolicy assertions

and security ontology’s concepts. At the current

stage, not all elements contained in an alternative

have a corresponding semantic concept. The reason

is twofold. First, the developed ontology focuses just

on main security concepts (integration of other con-

cepts is planned in the near future); second, some WS-

SecurityPolicy elements deal with technical aspects

which are not speciﬁcally bound to security (e.g., the

layout order). WS-SecurityPolicy terms that have no

correspondence in the ontology are simply ignored by

the Transformer.

Starting point for the mapping procedure is the

binding assertions. Depending on the token found

on those assertions, it is possible to derive the

protocols to be used. For instance, if the token is

one of wsp:ProtectionToken, wsp:InitiatorToken or

wsp:RecipientToken then both cipher and digital sign

protocols will have to be used. According to the key-

value map introduced earlier, semantic individuals

such as XML-Dsig and XML-Enc will be chosen to

semantically represent this option. Tokens such as

wsp:EncryptionToken, wsp:InitiatorEncryptionToken

or wsp:RecipientEncryptionToken only express the

need for a cipher protocol, and will be mapped

onto XML-Encryption, while for tokens like

wsp:SignatureToken, wsp:InitiatorSignatureToken

and wsp:RecipientSignatureToken the XML-

DigitalSignature protocol will correspond. Finally,

wsp:TransportToken will be mapped onto the Https

protocol.

The symmetric and asymmetric bindings guar-

antee protection at the message level, and will be

mapped on the hasSecurityScope property set to the

MessageLevelSecurity value. The transport binding

provides protection at the transport level: in that case,

that assertion will be mapped on the hasSecurityScope

property whose value will be set to TransportLevelSe-

curity.

In the case of wsp:ProtectionToken or

wsp:InitiatorToken, the speciﬁc type of token

used to guarantee protection is also speciﬁed. Among

all possible types, the mapping process supports

the following: “X509”, “SAML”, “Username” and

“Https”. The latter, in particular, is the only one

allowed as a transport token. The ﬁrst three tokens

specify that authentication credentials must be

provided. While “SAML” and “Username” have a

direct correspondence with protocols described by

the ontology (SAML and login protocol respectively),

“X509” does not have a direct correspondence; so in-

stead of mapping it onto a protocol it is mapped onto

the authentication security Objective. Furthermore,

in the case of “X509” the property indicating that an

X509 certiﬁcate credential is required must be added

to the used protocols. In the case of “Username”,

instead, a password may be required in the assertion:

if so, the OneTimePassword credential will be used.

Finally, for a “SAML” token we must add to the

protocols set a credentials to require the use of

SAML as a guarantee on the identity. An important

assertion is the AlgorithmSuite, which speciﬁes the

algorithms adopted in the security environments.

Depending on the assertion’s settings, those algo-

rithms must be added to the corresponding protocols.

For instance, if the assertion is set to “Basic256”,

1) the hasEncryptionAlgorithm property must be

added to the XML-Enc protocol, with its value set to

AES-256, and 2) the hasSignatureAlgorithm property

must be added to the XML-Dig protocol, with the

value set to SHA-1. Likewise, if there are assertions

specifying the use of key derivation within the token,

the corresponding algorithm will be added.

4.3 Semantic Discovery

We implemented a semantic discovery engine capable

of searching for correspondences between security re-

quirements and capabilities. Suppose that both the

customer (requestor) and the provider (service) have

expressed their requirements and capabilities in their

own policies. The engine operates this way: a) the

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

432

Table 1: Mapping between WS-SecurityPolcy terms and Semantic Concepts.

WS-SecurityPolicy term Semantic Concept

Https http://www.semanticweb.org/ontologies/security.owl#Https rdf:ID requirement/capability

XML-Enc http://www.semanticweb.org/ontologies/security.owl#XML-Enc rdf:ID requirement/capability

........ .................................................................................................

Authentication http://www.semanticweb.org/ontologies/security.owl#Authentication rdf:ID requirement/capability

........ .................................................................................................

TransportLevel http://www.semanticweb.org/ontologies/security.owl#hasSecurityScope rdf:resource

http://www.semanticweb.org/ontologies/security.owl#TransportLevelSecurity

AES256 http://www.semanticweb.org/ontologies/security.owl#hasEncryptionAlgorithm rdf:resource

http://www.semanticweb.org/ontologies/security.owl#AES-256

AES192 http://www.semanticweb.org/ontologies/security.owl#hasEncryptionAlgorithm rdf:resource

http://www.semanticweb.org/ontologies/security.owl#AES-192

AES128 http://www.semanticweb.org/ontologies/security.owl#hasEncryptionAlgorithm rdf:resource

http://www.semanticweb.org/ontologies/security.owl#AES-128

........ .................................................................................................

EncryptedBody http://www.semanticweb.org/ontologies/security.owl#encryptsPart rdf:resource

http://www.semanticweb.org/ontologies/security.owl#Body

SignedBody http://www.semanticweb.org/ontologies/security.owl#signsPart rdf:resource

http://www.semanticweb.org/ontologies/security.owl#Body

RequiredBody http://www.semanticweb.org/ontologies/security.owl#requiresPart rdf:resource

http://www.semanticweb.org/ontologies/security.owl#Body

........ .................................................................................................

SignSignature http://www.semanticweb.org/ontologies/security.owl#signsPart rdf:resource

http://www.semanticweb.org/ontologies/security.owl#Signature

SignSignatureToken http://www.semanticweb.org/ontologies/security.owl#signsPart rdf:resource

http://www.semanticweb.org/ontologies/security.owl#SigningToken

SignSupportingToken http://www.semanticweb.org/ontologies/security.owl#signsPart rdf:resource

http://www.semanticweb.org/ontologies/security.owl#SupportingToken

requirements of the service are compared to the ca-

pabilities of the requestor; b) the capabilities of the

service are compared to the requirements of the re-

questor. In order for the comparison process to have a

positive outcome, the two following conditions must

hold:

• the capabilities expressed in the service’s policy

must meet the requirements expressed in the re-

questor’s policy;

• the requirements expressed in the service’s policy

must be met by the capabilities expressed in the

requestor’s policy.

The ﬁrst step of the matchmaking process has to

assign a match level to each requirement-capability

pair. The comparison will leverage on the well-known

concepts of exact, subsume, plugin, and no match

(Paolucci et al., 2002), and has been carried out by

means of techniques that have already been explored

by authors in the context of supply-demand match-

making in cloud markets (Di Modica and Tomarchio,

2012).

In the second step the overall match between the

two policies is evaluated: the objective is to ﬁnd the

capability that matches at best for each requirement.

The overall match is then deﬁned to be the minimum

among the individual match levels evaluated in the

ﬁrst step for each requirement-capability pair. Fur-

ther details on the policy matching can be found in

a previous work (Di Modica and Tomarchio, 2011b),

even though in that work a preliminary version of the

ontology is employed.

5 CASE STUDY

In this section, an simple case study of the over-

all behaviour of the semantic security framework is

presented. The overall scenario is the classic sce-

nario (see also Figure 1) where a client (service

requestor) is looking for a service that provides a

speciﬁc functionality (expressed through the WSDL

speciﬁcation), with a speciﬁc security policy which

has been expressed using WS-SecurityPolicy asser-

tions; in addition, the client expresses also security

requirements (within its own security policy) that the

service provider must meet. The client searches the

UDDI registry in order to retrieve service informa-

tion. The registry, besides providing the information

necessary to invoke the service (the WSDL descrip-

tor), also returns the provider’s associated security

policy. The Transformer transforms this policy into

a semantically annotated policy.

At this point, the Matchmaker and the Reasoner

come into play, allowing the client to verify the fulﬁll-

ment of its security requirements. The Matchmaker is

fed with the client’s and the provider’s policies. It

ASemanticModeltoSupportSecurityMatchinginCloudEnvironments

433

then runs the matching algorithm and, with the help

of the Reasoner, evaluates the match level between

the policies. Finally the client, based on the obtained

value, decides whether to invoke the service or not.

5.1 Security Policies Deﬁnition

The service provider expresses its security policy

by using the standard WS-Policy framework, adopt-

ing WS-SecurityPolicy terms. The speciﬁc policy

has been taken by the example policies of WS-

SecurityPolicy speciﬁcation (OASIS, 2012). The sce-

nario provides for a requestor that wants to access

a service anonymously, and a service provider that

presents its credentials. In order to guarantee message

conﬁdentiality and authentication, the security proto-

col will use symmetric ephemeral keys, generated by

the provider and exchanged through asymmetric en-

cryption.

Provider Policy. The provider policy is composed

by multiple items: one at the endpoint level, and two

for input and output messages respectively. At the

upper level the the WS-SecurityPolicy elements are:

SymmetricBinding, EncryptedParts, SignedParts and

Wss11. Each element, in its turn, is characterized by

several properties (not described here for space rea-

son) better detailing the requirements and the capa-

bilities of the provider.

The Transformer module takes as input this

policy and provides a corresponding policy anno-

tated with semantic concepts. The resulting pol-

icy, which is shown in Listing 1, contains two re-

quirements and three capabilities. In order to im-

prove the readability of the listing, the namespace

htt p : //www.semanticweb.org/ontologies/security

was removed from each rdf:resource term.

Listing 1: Semantically enriched Policy.

< w s p:P o l icy >

< w s p :Ex a c t l yOn e >

< w sp: A ll >

< s e c u r ity: A u t h e n tica t i o n rdf :ID = " c a pab i l ity 0

"/ >

< s ec u rit y:X ML - En c r d f:I D = " ca p a b ili t y 1 " >

< s e c u r i t y :has K e y D e r i v a tionA l g o r i t h m

rdf : r eso u r c e = " # PS h a 1L 1 9 2 " / >

< s e c u r i ty:r e q u i r e s C rede n t i a l r df: r e s our c e = "

# X_5 0 9 C e rti f i c a te "/ >

< s e c u r i ty:h a s S e c u rity S c o p e r df: r e s our c e = " #

Mes s a g e L evel S e c u r ity " / >

< s e c u r i ty:r e q u i r e s C rede n t i a l r df: r e s our c e = "

# T i m est a m p "/ >

< s e c u r i t y:ha s E n c r y p t i onAl g o r i t h m

rdf : r eso u r c e = " # AES - 256 " / >

< s e c u r ity : e n c r y ptsP a r t r d f:r e s our c e = " # Bo dy "

/ >

</ s ecu rit y:X M L - En c >

< s ec u rit y:X ML - En c r d f:I D = " re q u i rem e n t 0 " >

< s e c u r i ty:h a s S e c u rity S c o p e r df: r e s our c e = " #

Mes s a g e L evel S e c u r ity " / >

< s e c u r i ty:r e q u i r e s C rede n t i a l r df: r e s our c e = "

# T i m est a m p "/ >

< s e c u r i t y:ha s E n c r y p t i onAl g o r i t h m

rdf : r eso u r c e = " # AES - 256 " / >

< s e c u r ity : e n c r y ptsP a r t r d f:r e s our c e = " # Bo dy "

/ >

</ s ecu rit y:X M L - En c >

< s ec u rit y:X ML - Dsi g r d f:I D = " ca p a b ili t y 2 " >

< s e c u r i t y :has K e y D e r i v a tionA l g o r i t h m

rdf : r eso u r c e = " # PS h a 1L 2 5 6 " / >

< s e c u r i ty:r e q u i r e s C rede n t i a l r df: r e s our c e = "

# X_5 0 9 C e rti f i c a te "/ >

< s e c u r i ty:h a s S e c u rity S c o p e r df: r e s our c e = " #

Mes s a g e L evel S e c u r ity " / >

< s e c u r i ty:r e q u i r e s C rede n t i a l r df: r e s our c e = "

# T i m est a m p "/ >

< s e c u r i t y:ha s S i g n a t u reAl g o r i t h m

rdf : r eso u r c e = " # SHA -1 " / >

< s e c u rity : s i g nsPa r t r d f:r e s o urc e = " # Bo dy " / >

</ s ecu rit y:X M L - Dsi g >

< s ec u rit y:X ML - Dsi g r d f:I D = " re q u i rem e n t 1 " >

< s e c u r i ty:h a s S e c u rity S c o p e r df: r e s our c e = " #

Mes s a g e L evel S e c u r ity " / >

< s e c u r i ty:r e q u i r e s C rede n t i a l r df: r e s our c e = "

# T i m est a m p "/ >

< s e c u r i t y:ha s S i g n a t u reAl g o r i t h m

rdf : r eso u r c e = " # SHA -1 " / >

< s e c u rity : s i g nsPa r t r d f:r e s o urc e = " # Bo dy " / >

</ s ecu rit y:X M L - Dsi g >

</ w sp: A ll >

</ w s p : Exa c t l yOn e >

</ w s p:P o l icy >

The requirements are the XML-Encryption and

the XML-DigitalSignature protocols, which are also

described with some properties imposing the speciﬁc

encryption algorithm to be used and the need to en-

crypt and sign the Body of the message.

The capabilities are the XML-Enc, XML-Dsig

and the Authentication assertions. The ﬁrst two are

similar to what already expressed into the require-

ments, except for some speciﬁc algorithms (the latter

represents a security objective ensured by the X.509

certiﬁcate).

Requestor Policy. The service requestor expresses

its policy in terms of requirements and security capa-

bilities too. In order to show the effectiveness of the

semantic matching algorithm, it was manually created

from the service provider policy, by inverting require-

ments with capabilities. Then, some elements and

properties have been modiﬁed in order to show the

reasoning capabilities of the framework. In particu-

lar:

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

434

• the ﬁrst requirement was changed into the SAML

protocol, that is, into a more speciﬁc requirement;

• in the second requirement, the hasSecurityScope

property was changed into CommunicationSecu-

rity;

• third requirement and ﬁrst capability were left un-

changed;

• in the second capability, the hasSignatureAlgo-

rithm property was changed into hasAlgorithm,

that is, into a less speciﬁc property.

5.2 Matching Results

The matching algorithm tries to combine the client

requirements with the server capabilities (and vice

versa) for each couple of policy alternatives. Since

in this example there is only one alternative, there

are no iterations among alternatives. The match level

found by the reasoner are the following:

Service Requirements versus Requestor Capabilities

• Possible Match: it derives from the compari-

son between the Authentication and SAML asser-

tions, since the requirement is more speciﬁc than

the capability

• Close Match: it derives from the comparison be-

tween the XML-Enc assertions which are iden-

tical in both policies, but have different proper-

ties. In particular the requirement property Com-

municationSecurity is more general than the Mes-

sageLevelSecurity property of the capability.

• Perfect Match: it derives from the comparison be-

tween the XML-Dsig assertions which are identi-

cal in both policies, and also have identical prop-

erties.

Service Capabilities versus Requestor Requirements

• Perfect Match: it derives from the comparison be-

tween the XML-Enc assertions which are identi-

cal in both policies, and also have identical prop-

erties.

• Possible Match: it derives from the comparison

between the XML-Dsig assertions which are iden-

tical in both policies, but have different properties.

In particular, the requirement property hasSigna-

tureAlgorithm is more speciﬁc than the capability

property hasAlgorithm.

The policies’ overall match level is given by the

lowest among the found levels: in this case it is a Pos-

sible match. The Matchmaker communicates to the

client that the selected service may satisfy its secu-

rity requirements. Since the match is not Perfect, the

client is required to provide additional information or

negotiate with the service provider before actually in-

voking the service. Further details on the negotiation

phase that may carried out at this step can be found in

(Liccardo et al., 2012).

It should be noticed that, if a traditional (syntac-

tic) approach had been used for the policy compari-

son, the result would have led us to consider the two

policies as incompatible.

6 CONCLUSIONS

Security has been acknowledged to be one of the pri-

mary concerns preventing a wide adoption of cloud

computing among enterprises. In interoperable con-

texts like those fostered by SOA, where networks of

trustiness must be set up among service providers,

deﬁning, modeling and matching service security

policies is a crucial problem that needs to be faced.

Existing proposals leveraging on a syntactic approach

like the WS-Policy are not very well suited for these

heterogeneous and dynamic scenarios. In this paper

we proposed to integrate the WS-Policy model with

semantic annotations, thus enabling semantic match-

ing capabilities, allowing to go beyond the strict syn-

tactic intersection of policy assertions.

We then developed a security ontology which al-

lows the relationships among main security concepts

to be modeled. Leveraging on this ontology, we de-

signed and implemented a framework for the match-

making of what is requested on the customer side and

what can be provided on the provider side in terms

of security features. The framework is also compat-

ible with syntactic policies deﬁned through the WS-

SecurityPolicy speciﬁcation. A procedure was de-

vised to transform the policy’s syntactic terms into

semantic concepts of our security ontology. A sim-

ple use case example was also proposed to show the

viability of the approach and the actual limits of the

pure syntactic-based approaches.

Future works will be aimed to test the framework

with interoperable scenarios (B2B scenarios) and to

interact with even more complex policies.

ACKNOWLEDGEMENTS

The work described in this paper has been partially

supported by the “Cloud4Business” project funded

by the PO FESR 2007/2013 programme of Sicily re-

gion.

ASemanticModeltoSupportSecurityMatchinginCloudEnvironments

435

REFERENCES

Damianou, N., Dulay, N., Lupu, E., and Sloman, M. (2001).

The ponder policy speciﬁcation language. In Proceed-

ings of the International Workshop on Policies for Dis-

tributed Systems and Networks, POLICY ’01, pages

18–38, London, UK. Springer-Verlag.

Di Modica, G. and Tomarchio, O. (2011a). Seman-

tic annotations for security policy matching in WS-

Policy. In SECRYPT 2011 - Proceedings of the Inter-

national Conference on Security and Cryptography,

pages 443–449, Seville (Spain).

Di Modica, G. and Tomarchio, O. (2011b). Semantic Secu-

rity Policy Matching in service oriented architectures.

In Proceedings - 2011 IEEE World Congress on Ser-

vices, SERVICES 2011, pages 399–405, Washington

DC (USA).

Di Modica, G. and Tomarchio, O. (2012). A semantic dis-

covery frame work to support supply-demand match-

making in cloud service markets. In CLOSER 2012

- Proceedings of the 2nd International Conference on

Cloud Computing and Services Science, pages 533–

541, Porto (Portugal).

Garcia, D. Z. G. a. and Felgar de Toledo, M. B. (2008).

Ontology-Based Security Policies for Supporting the

Management of Web Service Business Processes. In

2008 IEEE International Conference on Semantic

Computing, pages 331–338. Ieee.

Kagal, L., Finin, T., and Joshi, A. (2003). A policy language

for a pervasive computing environment. In Proceed-

ings of the 4th IEEE International Workshop on Poli-

cies for Distributed Systems and Networks, POLICY

’03, pages 63–, Washington, DC, USA. IEEE Com-

puter Society.

Kim, A., Luo, J., and Kang, M. (2005). Security ontol-

ogy for annotating resources. In On the Move to

Meaningful Internet Systems 2005: CoopIS, DOA,

and ODBASE, pages 1483–1499. Springer.

Liccardo, L., Rak, M., Di Modica, G., and Tomarchio, O.

(2012). Ontology-based Negotiation of Security Re-

quirements in Cloud. In Computational Aspects of

Social Networks (CASoN), 2012 Fourth International

Conference on, pages 192 –197, Sao Carlos (Brasil).

OASIS (2012). WS-SecurityPolicy 1.3. OASIS Standard.

Available at http://www.oasis-open.org/specs/.

Paolucci, M., Kawamura, T., Payne, T. R., and Sycara, K. P.

(2002). Semantic matching of web services capabil-

ities. In ISWC ’02: Proceedings of the First Inter-

national Semantic Web Conference on The Semantic

Web, pages 333–347, London, UK. Springer-Verlag.

Papazoglou, M. P. and van den Heuvel, W.-J. (2007). Ser-

vice Oriented Architectures: approaches, technolo-

gies and research issues. VLDB Journal, 16(3):389–

415.

Phan, T., Han, J., Schneider, J., Ebringer, T., and Rogers,

T. (2008). A survey of policy-based management ap-

proaches for Service Oriented Systems. In Software

Engineering, 2008. ASWEC 2008. 19th Australian

Conference on, pages 392–401. IEEE.

Speiser, S. (2010). Semantic Annotations for WS-Policy.

In IEEE International Conference on Web Services

(ICWS 2010), pages 449–456. IEEE.

Sriharee, N., Senivongse, T., Verma, K., and Sheth, A.

(2004). On using ws-policy, ontology, and rule rea-

soning to discover web services. In Intelligence in

Communication Systems, number May 2004, pages

246–255. Springer.

Tonti, G., Bradshaw, J., Jeffers, R., Montanari, R., Suri, N.,

and Uszok, A. (2003). Semantic Web languages for

policy representation and reasoning: A comparison of

KAoS, Rei, and Ponder. In International Semantic

Web Conference (ISWC2003), pages 419–437, Florida

(USA). Springer.

Uszok, A., Bradshaw, J., Jeffers, R., Suri, N., Hayes, P.,

Breedy, M., Bunch, L., Johnson, M., Kulkarni, S., and

Lott, J. (2003). Kaos policy and domain services: To-

ward a description-logic approach to policy represen-

tation, deconﬂiction, and enforcement. In Proceed-

ings of the 4th IEEE International Workshop on Poli-

cies for Distributed Systems and Networks, POLICY

’03, pages 93–, Washington, DC, USA. IEEE Com-

puter Society.

Verma, K., Akkiraju, R., and Goodwin, R. (2005). Semantic

matching of Web service policies. In Semantic Web

Policy Workshop (SDWP 2005).

W3C (2007). Web services policy 1.5 - framework. W3C

Recommendation. Available at http://www.w3.org/

TR/ws-policy/.

Zheng-qiu, H., Li-fa, W., Zheng, H., and Hai-guang, L.

(2009). Semantic Security Policy for Web Service. In

2009 IEEE International Symposium on Parallel and

Distributed Processing with Applications, pages 258–

262. Ieee.

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

436