A POLICY-BASED APPROACH TO SECURE CONTEXT

IN A WEB SERVICES ENVIRONMENT

Zakaria Maamar

, Ghita Kouadri Most

efaoui

and Djamal Benslimane

Zayed University, Dubai, U.A.E.

University of Montreal, Montreal, Canada

Claude Bernard Lyon 1 University, Lyon, France

Keywords:

Context, Policy, Security, Web service.

Abstract:

This paper presents a policy-based approach for securing the contexts associated with Web services, users, and

computing resources. Users interact with Web services for personalization needs, and Web services interact

with resources for performance needs. To authorize any context change, a security context is developed. The

security context reports on the strategies that protect a context using authorization and restriction policies.

1 INTRODUCTION

Over the last three years, we have been inves-

tigating Web services along the following direc-

tions: context-aware composition, personalization,

self-coordination, semantic mediation, and last but

not least tracking (Benslimane et al., 2005; Maamar

et al., 2006a). This paper continues our investigation

of Web services personalization (Maamar et al., 2005)

with emphasis this time on securing the content of the

contexts of the components that participate in such a

personalization.

User, Web service, and resource represent these

components. Users trigger Web services to satisfy

their needs, and Web services operate on top of re-

sources during computing. To track the progress

of interaction that happen between users and web

service, and then between Web services and re-

sources, speciﬁc structures of type context are de-

vised (Fig. 1). In (Maamar et al., 2005), we special-

ized context into user context (U -context), Web ser-

vice context (W-context), and resource context (R-

context). Coutaz et al. argue that ”context is not sim-

ply the state of a predeﬁned environment with a ﬁxed

set of interaction resources. It is part of a process of

interacting with an ever-changing environment com-

posed of reconﬁgurable, migratory, distributed, and

multiscale resources” (Coutaz et al., 2005).

It is widely agreed that any tracking operation relies

on the quality of information that is collected, reﬁned,

and used for feeding this operation. A poor quality

of information usually results in making wrong de-

cisions, which affect for example the chronology of

operations to execute, the scheduling of resources to

use, and the type of data to exchange. The support in-

formation for tracking purposes represents the content

of a context whether of type U , W ,orR. In this pa-

per, we discuss the rationale of securing the content of

these three contexts and the mechanisms that are set

up for authorizing or restricting the management of

this content by using speciﬁc policies. Management

means here consultation and update.

Our security approach is built upon a forth type

of context, which we extend from context and refer

to as security context (S-context). While the three

aforementioned types of context are responsible for

catering information on users, Web services, and re-

sources, respectively, the security context is respon-

sible for overseeing their U /S/R-contexts (Fig. 1).

Therefore the security context is specialized into three

types: S-context

(Security context of U ser context),

S-context

(Security context of W eb service con-

text), and S-context

(Security context of Resource

context). Fig. 1 illustrates 2 types of link between

contexts: to extend for specialization purposes and to

oversee for tracking purposes.

By promoting security context, our objective is

to track all the concerns and threats that affect the

content of a context, to deploy appropriate measures

based on previous security contexts, and to adjust

the measures subject to the feedbacks obtained out

of this tracking. Some of the elements that could

be identiﬁed through a security context are multiple

like the regular actions for identiﬁcation and encryp-

tion/decryption, the types of violation that targeted

the protective measures, and the corrective actions

that are run for ﬁxing misuse or alteration situations.

Section 2 discusses the rationale of a security con-

100

Maamar Z., Kouadri Mostéfaoui G. and Benslimane D. (2006).

A POLICY-BASED APPROACH TO SECURE CONTEXT IN A WEB SERVICES ENVIRONMENT.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - SAIC, pages 100-105

DOI: 10.5220/0002443001000105

 SciTePress

S-context

Context

To extend

U-context

(users)

S-context

W-context

(Web services)

R-context

(Resources)

To extendTo oversee To oversee To oversee

W-context Web service context U-context User context

Legend

R-context Resource contextS-context Security context

Figure 1: Types of context in a Web services environment.

text and overviews the Web services personalization

project as a running case. Section 3 explains our ap-

proach to securing the management of the content of

contexts by using security context. Section 4 presents

the prototype and Section 5 overviews some related

works. Conclusions are drawn in Section 6.

2 BACKGROUND

2.1 Why a Security Context?

A security context is a state of the working environ-

ment that requires taking one or more security ac-

tions. A security context is formed by a set of infor-

mation collected from the user’s environment and the

application environment and that is relevant to the se-

curity infrastructure of both the user and the applica-

tion (Kouadri Most

efaoui and Br

ezillon, 2004).

We expect that a security context will highlight the

elements that deﬁne the security of the context con-

tent of the components that are engaged in Web ser-

vices personalization. These elements are the encryp-

tion algorithm, the authentication operation, the con-

ﬁdentiality tool, etc. For instance, if a Web service

needs to be authenticated prior to managing its con-

text, it will have to comply with this procedure. In

addition we expect that the security context will limit

the changes in the content of a context. For instance,

a Web service could refrain from submitting consulta-

tion requests to its context because of the interception

threats that originate from a resource.

2.2 Application Case: Web Services

Personalization

A complete description of the Web services person-

alization project, which integrates the three types of

context (i.e., U -context, W -context, and R-context)

into its operation is given in (Maamar et al., 2005).

In the following we only overview this project by fo-

cussing on the interactions that occur during Web ser-

vices personalization.

Fig. 2 illustrates the interactions that take place dur-

ing context-based personalization of Web services be-

fore considering security. When a user selects a Web

service, he continues afterwards with the personaliza-

tion of this Web service according to time or location

preferences. Time preference is twofold: when the

execution of the Web service should start, and when

the outcome of this execution should be delivered to

the user back. Location preference is attached to user

and is twofold: where the execution of the Web ser-

vice should occur, and where the outcome of this ex-

ecution should be returned to the user.

Web serviceUser Resource

Identification + preferences

yes/Identification

W-context

Capability

assessment

R-context

Capability

assessment

R-context

Update

W-context

Update

no no

Notification/yes

Notification

U-context

Update

Legend

Trigger Process Branching EndInteraction

Figure 2: Interactions during Web services personalization.

Once the preferences of a user are submitted to the

Web service, this latter ensures that the dates and lo-

cations are valid as conﬂicts might emerge during op-

eration (e.g., delivery time occurring before execution

time). Before the identiﬁcation of the resources on

which it will operate, the Web service checks its W-

context with regard ﬁrst, to the number of current ac-

tive participations in compositions vs. the maximum

number of active participations in compositions and

second, to the next period of unavailability. After a

positive check of the W -context content (to be se-

cured), the identiﬁcation of a resource can now start.

A resource mainly needs to accommodate the start-

ing time of the execution of a Web service, and the

time that the execution of a Web service lasts. The

outcome of this execution is tightened to the deliv-

ery time as per user’s indication. To this purpose

a resource checks its R-context with regard ﬁrst, to

the next periods of time that will feature the execu-

tion of Web services and second, to the next period of

maintenance. After a positive check of the R-context

content (to be secured), the resource notiﬁes the Web

service, which itself proceeds with notifying the user

when the response of his request is ready for delivery.

A POLICY-BASED APPROACH TO SECURE CONTEXT IN A WEB SERVICES ENVIRONMENT

101

The various notiﬁcations among these three compo-

nents result in updating the content of the different

contexts (Fig. 2). It will be shown in the next section

the way these update operations are monitored.

3 POLICIES TO PROTECT

CONTEXT

3.1 Protection Strategy

The aim of the security context is twofold. The

ﬁrst aim is to announce the security mechanisms,

which guarantee the necessary protection of U/W /R-

contexts in terms of authentication, message safety,

and data integrity. This aim was already investigated

in our previous research on context ontologies (Maa-

mar et al., 2006b). A non-authorized access to a con-

text could result in an inaccurate assessment of multi-

ple elements like location of user, execution status of

a Web service, or capacity of a resource. The second

aim, focus of this paper, is to keep track at the level

of the security context (S-context

U/W/R

) of all the

operations that users/Web services/resources initiate

over the content of their respective U/W/R-contexts.

Operations on a context content are multiple rang-

ing from consultation and modiﬁcation to content ex-

change between contexts. The sensitive nature of the

content of contexts, as emphasized by the ﬁrst aim

of the security context, has motivated the develop-

ment of a set of policies that frame the performance

of these operations based ﬁrst, on the status of the en-

vironment surrounding users/Web services/resources

and second, on previous experiences of running sim-

ilar operations. For instance, a Web service could

refrain from consulting its W -context’s parameters if

this Web service ﬁnds out that the resource, on which

it operates, can intercept and modify content. In this

paper, we use Ponder (Damianou, 2002) to specify

the various policies per type of context and per type

of operation to be run over this context content.

Fig. 3 illustrates our proposed policy-based archi-

tecture for protecting a context content. The archi-

tecture highlights three components namely user, re-

source, and Web service, and a repository of poli-

cies (to be associated with an authorization engine).

To keep Fig. 3 clear, the way these three compo-

nents are ”plunged” in the surrounding environment

is represented with the shape overlapping between

”user/resource/Web service” rectangle and ”environ-

ment” cloud. Each component binds to a context

that is overseen by a security context. A compo-

nent carries out operations over the content of its

context upon receiving approval from the reposi-

tory of policies (i.e., the authorization engine). This

approval is the result of triggering policies based

on the inputs that the repository receives after as-

sessing the environment and consulting the secu-

rity context. We have developed two types of

policies in compliance with the types of policies

in Ponder: authorization and restriction.Asex-

ample of a policy speciﬁcation is given in Sec-

tion 3.2. The input from the environment is about

user (location, status

{busy,resting,etc.}

, etc.), Web ser-

vice (status

{active,suspended,etc.}

, provider identiﬁer,

QoS, etc.), and resource (load

{high,low,etc.}

, provider

identiﬁer, QoS, etc.). The input from the security

context is about previous experiences, which have

dealt with the content of context. Previous experience

refers to a similar operation over a context content that

occurred in the past and was reported at the level of

the security context. Any change in the content of a

context is immediately communicated to the security

context. A change is illustrated by setting new val-

ues to parameters of contexts, modifying the update

ﬂag of a parameter from ”permitted” to ”unpermit-

ted”, modifying the consultation ﬂag of a parameter

from ”authorized” to ”unauthorized”, etc. In Fig. 3,

number duplication means concurrent operations.

4- Management

S-context

U/ R/ W

User

Resource

Web service

3- Operation

subject to approval

5- To report5- To oversee

U/ R/ W-context

2- Approval (y/n)

Repository of policies

1- Input1- Input

Environment

0- Assessment

Figure 3: Architecture for content protection of context.

Our development strategy for a security context of

types user/Web service/resource (S -context

U/W/R

)

consists of three steps: threat identiﬁcation, security-

context organization, and policy speciﬁcation.

Threat identiﬁcation step consists of list-

ing the threats that could abstain a component

(user/resource/Web service) from managing the con-

tent of its context. We classify the threats according

to their origin.

- Threats on the content of U -context of user pri-

marily originate from Web services. Once a Web

service is selected for participation in a composi-

tion, the Web service could turn out to be untrust-

worthy during run-time. Indeed, subject to per-

sonalization at the levels of execution time or ex-

ecution location, a Web service may aim at mod-

ifying some preferences of user without consult-

ing him. A motivate for the modiﬁcation could be

the large number of user requests that the Web ser-

vice has accepted to satisfy, exceeding thus its ca-

pabilities. Since U -context’s and W-context’s pa-

rameters overlap (Maamar et al., 2005), the user

is requested to modify the values of some his U -

context’s parameters in accordance with the latest

ICEIS 2006 - SOFTWARE AGENTS AND INTERNET COMPUTING

102

Table 1: Description of S-context

U /W/R

’s parameters and their instantiation.

Parameter & Description

Label context: identiﬁes the context of the component that the security context is associated with.

Operation source: identiﬁes the component that intends running an operation over a context content.

- Operation type: indicates if it is a consultation or modiﬁcation operation.

- Source trustworthiness: indicates how much the component that binds to a context trusts the component

that intends running an operation over this context content (null if both components are the same).

Parameter list: indicates the parameters of a context that are included in the operation of the component.

- Last operation(s) outcome: identiﬁes the performance outcome in terms of success or failure of a similar

operation(s) that the component binding to a context has received in the past from another component.

- Operation validation and outcome: indicates if the current operation over a context content is approved or

denied (if trustworthiness of source is set to null, then operation validation is by default set to approved) and

what the outcome of this performance is in terms of success or failure.

Date: identiﬁes the time of updating the parameters above.

Parameter & Instantiation

Label context: U-context

(context of user

Operation source: Web service

- Operation type: modiﬁcation.

- Source trustworthiness: high (user

highly trusts of Web service

Parameter list: parameter

, parameter

- Last operation(s) outcome: null (ﬁrst time).

- Operation validation and outcome: approved/failure (the operation of Web service

was approved but its

execution failed).

Date: 5/5/2005.

Remark: component refers to user, Web service, or resource; context refers to U/W/R-context.

changes in the W-context’s parameters. If the Web

service is classiﬁed as untrustworthy and a similar

modiﬁcation request has repetitively been issued by

the same Web service, restriction policies should

prevent the user from modifying U -context. De-

tails on the trust level of a Web service and type of

request are contained in the security context (see

Step 2 for details). Contrary to restriction poli-

cies, authorization policies permit the modiﬁcation

of the U -context’s parameters if for example the re-

cent changes in the preferences of user at the Web

service level still meet the user requirements.

- Threats on the content of W -context of a Web ser-

vice have two origins: user and resource. Regard-

ing the user origin, the aforementioned scenario

that describes the threats on U -context of user is

still valid once the threat direction is reversed. This

time the user, instead of the Web service, aims at

modifying his preferences without consulting the

Web service. The Web service either accepts or re-

jects modifying the W -context. Modiﬁcation re-

jection could be motivated by the lack of resources

on which the Web service would run. And modiﬁ-

cation acceptance could be motivated by the conﬁ-

dence level that the Web service aims at increasing

towards this user.

Regarding the resource origin, a Web service needs

computing resources on which it operates. In ad-

dition to the overlapping situation between W-

context’s and R-context’s parameters (where a

change in W-context has to be reﬂected on R-

context too), the resource can request some pri-

vate data from the W -context of a Web service for

different purposes related to tracing current exe-

cutions or scheduling forthcoming executions. A

resource could accept additional Web services for

execution if it could establish the various partici-

pations of this Web service in other compositions.

While this threat (private-data access) could be ad-

dressed using authentication, the resource needs to

be informed about the authentication mechanism

that it needs to comply with prior to any attempt

of consulting W-context. This mechanism type

is known as per the ﬁrst aim of the security con-

text (Maamar et al., 2006b).

- Threats on the content of R-context of a resource

originate from Web services. The aforementioned

scenario that describes the threats on W-context of

A POLICY-BASED APPROACH TO SECURE CONTEXT IN A WEB SERVICES ENVIRONMENT

103

inst autho+ AuthorizationModiﬁcation{

subject s = per Web service

target t = /User

when s.trustworthinessofsource(”high”) & s.operationtype(”modiﬁcation”) & s.lastoperationoutcome(”success”)

action ModifyContext(1[t.set(parameter,value)])&Update(t.set(operationvalidation,approved))

& Update(t.set(operationoutcome,success—failure))}

Figure 4: Sample of an authorization policy in Ponder.

a Web service is still valid once the threat direc-

tion is reversed. This time the Web service, instead

of the resource, aims at modifying some execution

parameters without consulting the resource. The

resource either accepts or rejects modifying the R-

context. Modiﬁcation acceptance could be moti-

vated by the availability of the resource on which

the Web service was planned running. And modiﬁ-

cation rejection could be rejected by the repetitive

requests that originate from this Web service.

Security-context organization step is to iden-

tify the parameters of the security context (S-

context

U/W/R

) per component type so ﬁrst, oversee-

ing the changes in the content of contexts properly

happens and second, building a bank of previous ex-

periences occurs (Fig. 3). At this stage of our re-

search, we have identiﬁed the following parameters

independently of the type of security context (Ta-

ble 1). In the second part of this table, we provide

an instantiation example of these parameters.

Policy speciﬁcation step consists of working on

the policies that manage the content of U /W/R-

contexts. This is detailed in Section 3.2. Policies per-

mit a dynamic management of the content of a con-

text. Each management request is veriﬁed using poli-

cies. Furthermore policies can be changed on-the-ﬂy

in response to changing conditions.

3.2 Management Strategy

Our motive for adopting policies is to frame the op-

erations that are carried out over the content of con-

texts according to the state of the surrounding envi-

ronment and previous experiences. We selected Pon-

der for policy speciﬁcation in compliance with some

requirements that need to be satisﬁed like expressive-

ness, simplicity, and scalability (Tonti et al., 2003).

Ponder permits developing different types of poli-

cies like authorization (positive or negative) and

obligation. Fig. 4 shows an authorization policy in

Ponder to modify the content of a context. The mod-

iﬁcation request originates from Web service

to U -

context of user

. The conditions that this request is

subject to are associated with when label and summa-

rized as follows: trustworthiness level of Web service

is high, type of operation is modiﬁcation, and out-

come of a similar operation in the past is success.

When these conditions are satisﬁed, actions are per-

formed: set the values of the parameters of U-context,

update the operation validation with approval, and ﬁ-

nally update the operation outcome with either suc-

cess or failure.

4 PROTOTYPE

We overview the implementation of securing contexts

during Web services personalization. This implemen-

tation continues the prototype we developed in (Maa-

mar et al., 2005). Fig. 5 illustrates the architecture of

the prototype. Seen from a horizontal perspective, the

prototype shows the different relationships that ex-

ist ﬁrst, between components (i.e., user, Web service,

and resource) and component contexts, and second,

between component contexts and security contexts.

These relationships are denoted by content manage-

ment and supervision, respectively. Content manage-

ment needs to be approved by an authorization en-

gine, which is fed with the outcome of triggering poli-

cies deﬁned

a la Ponder, the current status of the envi-

ronment, and previous experiences related to this con-

tent management.

Users

(context managers)

Web services

(context managers)

Authorization

engine

Repository

of policies

Triggering

Resources

(context managers)

Environment

Context

feeding

Repository

of U-contexts

Repository

of W-contexts

Repository

of R-contexts

Repository

of S-contexts

Repository

of S-contexts

Repository

of S-contexts

Content

management

SupervisionSupervision Supervision

Report

Previous context feeding

Content

management

Content

management

Content management approval (y/n)

Policy editor

Feedback

Figure 5: Architecture of the prototype.

Seen from a vertical perspective, the prototype

shows the triple (component, component context, se-

curity context). The content management of any com-

ponent context is reported at the level of the security

context. This report is stored for later use by the au-

ICEIS 2006 - SOFTWARE AGENTS AND INTERNET COMPUTING

104

thorization engine as part of previous experiences of

content management.

5 RELATED WORK

In security, the use of policies is usually geared to-

wards the speciﬁcation of security mechanisms that

must ensure authentication, message privacy, and au-

thorization of Web services. We report such efforts.

In (Anderson, 2004), Anderson adopts the Web

Services Policy Language (WSPL) to express poli-

cies and achieve Web services interoperability. She

claims that a Web service has various aspects and fea-

tures that can be controlled or described using policy

rules. Examples of such aspects are authentication,

quality-of-service, privacy, and reliable messaging.

Other languages for policy speciﬁcation exist

such as the Web Service Policy Framework (WS-

Policy) (Nolan, 2004). A WS-Policy speciﬁcation

deﬁnes a syntax and semantics for service providers

and service requestors to describe their requirements,

preferences, and capabilities. The syntax provides a

ﬂexible and concise way of expressing the needs of

each domain in the form of policies. A domain in

this context is a generic ﬁeld of interest that applies

to the service and can illustrate one of the following

aspects: security, privacy, application priorities, user

account priorities, and trafﬁc control.

Other service-speciﬁc policies have been proposed.

Privacy policies discussed in (Yee and Korba, 2004)

are an example. Yee and Korba propose a pri-

vacy policy negotiation approach to protect privacy

of Web services users. Along the same direction, In-

drakanti et al. make use of the XML Access Control

Language (XACL) to specify authorization policies

for patient records in healthcare systems implemented

as Web services (Indrakanti et al., 2004).

6 CONCLUSION

In this paper we presented a policy-based approach

that aims at securing the contexts associated with Web

services, users, and resources. To authorize any con-

text change, we suggested the development of a secu-

rity context that reports on the strategies that protect

a context using authorization and restriction policies.

These policies protect context from alteration or mis-

use risks by framing the management operations over

this context. By promoting security context, our ob-

jective was to track all the concerns and threats that

affect the content of a context, to deploy appropriate

measures based on previous security contexts, and to

adjust the measures subject to the feedbacks obtained

out of this tracking.

REFERENCES

Anderson, A. H. (2004). An Introduction to The Web

Services Policy Language (WSPL). In Proceedings

of The 5th IEEE Int. Workshop on Policies for Dis-

tributed Systems and Networks (POLICY’2004),New-

York, USA.

Benslimane, D., Mamaar, Z., and Ghedira, C. (2005). A

View-based Approach for Tracking Composite Web

Services. In Proceedings of The Third European Con-

ference on Web Services (ECOWS’2005), Vaxjo, Swe-

den.

Coutaz, J., Crowley, J. L., Dobson, S., and Garlan, D.

(2005). Context is Key. Communications of the ACM,

48(3).

Damianou, N. C. (2002). A Policy Framework for Man-

agement of Distributed Systems. PhD thesis, Imperial

College of Science, Technology and Medicine, Uni-

versity of London, Department of Computing.

Indrakanti, S., Varadharajan, V., and Hitchens, M. (2004).

Authorization Service for Web Services and its Imple-

mentation. In Proceedings of The IEEE Int. Confer-

ence on Web Services (ICWS’2004), San Diego, Cali-

fornia, USA.

Kouadri Most

efaoui, G. and Br

ezillon, P. (2004). Model-

ing Context-Based Security Policies with Contextual

Graphs. In Proceedings of The Workshop on Con-

text Modeling and Reasoning (CoMoRea’2004) held

in conjunction with The 2nd IEEE Int. Conference

on Pervasive Computing and Communication (Per-

Com’2004), Orlando, Florida, USA.

Maamar, Z., Benslimane, D., and Narendra, N. C. (2006a).

What Can Context do for Web Services? Communi-

cations of the ACM. (to appear).

Maamar, Z., Kouadri Most

efaoui, S., and Mahmoud, Q. H.

(2005). On Personalizing Web Services Using Con-

text. Int. Journal of E-Business Research, Special Is-

sue on E-Services, 1(3).

Maamar, Z., Narendra, N. C., and Sattanathan, S. (2006b).

Towards an Ontology-based Approach for Specifying

and Securing Web Services. Journal of Information &

Software Technology, Elsevier Science Publisher. (to

appear).

Nolan, P. (2004). Understand WS-Policy processing. Tech-

nical report, IBM Corporation.

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 Proceedings of The

Second Int. Semantic Web Conference (ISWC’2003),

Sanibel Island, Florida, USA.

Yee, G. and Korba, L. (2004). Privacy Policy Compliance

for Web Services. In Proceedings of The IEEE Int.

Conference on Web Services (ICWS 2004), San Diego,

California, USA.

A POLICY-BASED APPROACH TO SECURE CONTEXT IN A WEB SERVICES ENVIRONMENT

105