cerias tech report 2005-98 ws-ac: a fine grained access

CERIAS Tech Report 2005-98

WS-AC: A FINE GRAINED ACCESS CONTROL SYSTEM FOR WEB SERVICES

by ELISA BERTINO , ANNA C. SQUICCIARINI , IVAN PALOSCIA , LORENZO MARTINO

Center for Education and Research in Information Assurance and Security,

Purdue University, West Lafayette, IN 47907-2086

World Wide Web: Internet and Web Information Systems, 9, 143–171, 2006c© 2006 Springer Science + Business Media, LLC. Manufactured in The Netherlands.

DOI: 10.1007/s11280-005-3045-4

Ws-AC: A Fine Grained Access Control Systemfor Web Services

ELISA BERTINO [email protected] Sciences Department and CERIAS, Purdue University, West Lafayette

ANNA C. SQUICCIARINI [email protected] PALOSCIA [email protected] MARTINO [email protected] di Informatica e Comunicazione, Universita’ degli Studi di Milano

Published online: 20 September 2005

Abstract

The emerging Web service technology has enabled the development of Internet-based applications thatintegrate distributed and heterogeneous systems and processes which are owned by different organizations.However, while Web services are rapidly becoming a fundamental paradigm for the development of complexWeb applications, several security issues still need to be addressed. Among the various open issues concerningsecurity, an important issue is represented by the development of suitable access control models, able to restrictaccess to Web services to authorized users. In this paper we present an innovative access control model forWeb services. The model is characterized by a number of key features, including identity attributes andservice negotiation capabilities. We formally define the protocol for carrying on negotiations, by specifyingthe types of message to be exchanged and their contents, based on which requestor and provider can reach anagreement about security requirements and services. We also discuss the architecture of the prototype we arecurrently implementing. As part of the architecture we propose a mechanism for mapping our policies ontothe WS-Policy standard which provides a standardized grammar for expressing Web services policies.

Keywords: security, access control, distributed systems, web services, negotiation

1. Introduction

Nowadays the Web abounds with examples of Web-based enterprise services, and thereis an increasing trend amongst them to migrate to the Web services platform in orderto enhance and diversify the online services provided to their customers. While shiftingfrom the traditional client-server architecture to WS technology is seen as an endorse-ment of the Internet community’s faith in the promise of the Web services paradigm,the goals of interoperability and ubiquity as envisioned by the WS technology canonly reasonably be realized if the unique security challenges posed by this paradigmare appropriately addressed. Security is indeed critical to the wide-scale adoption andintegration of Web Services (WS) in distributed enterprise systems and software. Someapproaches for securing Web services have been proposed [1, 6, 16] over the last twoyears. In particular, the SAML [6] and XACML [16] standards provide a sound basisfor the development of the secure infrastructure for Web services. SAML, acronymfor Security assertion markup language, is an XML based framework for exchanging

144 BERTINO ET AL.

security information, which has been developed by the OASIS XML-Based SecurityServices Technical Committee. XACML is a specification that is used in conjunctionwith SAML, and it provides a means for standardizing access control decision forXML documents. Among the various open issues concerning security, an importantissue is the development of suitable access control models, able to restrict access toWeb services to authorized users. Even though several access control languages havebeen developed over the past few years, Web services have some specific requirementsthat require extensions to current access control languages with additional features.In particular, Web services are quite different with respect to objects typically pro-tected in conventional systems, like files or documents, since they consist of softwaremodules, to be executed, upon service requests, according to a set of associated in-put parameters. Moreover, because Web Services are often published and located onthe Web, potential users may belong to different domains and not be known to theparties providing the services. In such a context, traditional access control models areinadequate.

To address the above issues, we propose a novel access control model for Webservices, for use within the SOAP [3] standard, characterized by capabilities for ne-gotiating service parameters. The goal of our model, referred to as Ws-AccessControl(Ws-AC for short), is to express, validate and enforce access control policies with-out assuming pre-established trust in the users of the web services, while at the sametime being in line with recent developments on identity management [5]. Access con-ditions in Ws-AC are thus expressed in terms of identity attributes1 (attributes, forshort) of the requesters. Moreover, in order to support a fine tuning of access control,access conditions take into account the parameters characterizing the web services.It is thus possible to specify that a user is authorized to use a given web servicebut only for some specific values of the service parameters. Furthermore our modelsupports the concept of access negotiation. Although the notion of negotiation hasbeen extensively used in secure communication protocols to establish trust amongentities, this notion is only now being investigated in the context of access controlpolicies.

Web service negotiation in Ws-AC deals with the possibility for trusted2 users todynamically change their access requests in order to obtain authorizations, followingthe suggestions provided by web servers. The negotiation option makes Ws-AC anadaptive system able to drive the subjects toward the specification of acceptableaccess requests. Counterproposals are dynamically determined by servers duringthe negotiation. To better address user requests, counterproposals convey acceptableparameter values extracted from original access requests. User trustworthiness is, inour approach, a precondition for negotiating web service properties, and is achieved byenclosing attribute certificates with access requests.

In this paper, besides presenting Ws-AC, we propose a system architecture imple-menting the model, and show how to express Ws-Ac access control policies in a formatcompliant to WS-Policy [7] the current standard for Web service policy specification.

The remainder of the paper is organized as follows. Next section provides a detailedoverview of recent efforts of the Web Service research community for securing webservices. Section 3 formally defines the access control model we have designed. Inparticular, in Section 3.3 we show how to encode Ws-AC policies using Ws-Policy. InSection 4 we focus on the protocol supporting web service negotiations and present

A FINE GRAINED ACCESS CONTROL SYSTEM FOR WEB SERVICES 145

related algorithms. Section 5 presents the system architecture implementing Ws-AC.Finally, Section 6 concludes the paper with pointers to future directions.

2. Web Services security standards

Interoperability and security were the main business and technical drivers underpinningthe development of the Web Services standard stack framework. This framework, de-picted in Figure 1, is the result of the ongoing efforts of several international standardorganizations such as Internet Engineering Task Force (IETF) and the W3C, and otherinitiatives such as OASIS (Organization for the Advancement of Structured Informa-tion Standards), a not-for-profit, international consortium that drives the development,convergence, and adoption of e-business standards.

As far as WS security is concerned, it became apparent that the security requirementsposed by WS could not be solved by using the HTTPS protocol. HTTPS providesa point-to-point security, that lasts only for the duration of the connection; moreoverHTTPS has weak integrity concept, it provides an “all or nothing” encryption capability,and it does not support other security mechanisms. Rather, as illustrated by Figure 1,a comprehensive solution addressing the challenges posed by security of Web Servicescan be articulated according to three levels. At the bottom levels (Messaging & Encodingand Transport layers in Figure 1 above), one must provide basic mechanisms assuringintegrity and confidentiality of XML data; this is essential since WS technology heavilyrelies on XML for interoperation. At the intermediate level (Messaging box in Figure1), one must provide secure messaging protocols. At the top level (Security, Reliabilityand Transactions in Figure 1) one must assure confidentiality and integrity of messagesconveying service invocations and service execution results, and must provide supportfor authenticating the parties involved in service request exchanges. Moreover, one mustprovide support for application-dependent access control policies, specifying whichsubjects may use which services under which conditions.

Figure 1. Ws-Security stack

146 BERTINO ET AL.

Web Services Security specifications can be further detailed according to the roadmapproposed by IBM and Microsoft in April 2002 [10].

• WS-Security. WS-Security [3] defines enhancements to SOAP messaging to providemessage integrity and message confidentiality. To achieve this goal, WS-Securityspecifies how to apply XML Signature and XML Encryption within a SOAP message,in order to provide single-message authentication (origin authentication and integrity)and single-message confidentiality, and it specifies how to attach, or refer to, theassociated security tokens (for example, X.509 certificates) in a SOAP message.

• WS-Trust. WS-Trust [8] defines extensions to WS-Security that enable applicationsto construct trusted SOAP message exchanges. Trust is established through exchangeand brokering of security tokens. WS-Trust specifies how to request, issue, validate,and exchange security tokens. Security tokens are cryptographically protected claims(e.g., identity or authorization assertion) and/or cryptographic keys. Security tokensmay be forwardable, delegatable, or proxiable. Security tokens are issued by a SecurityToken Service (STS). Security token requests may be secured using WS-Security(when exchanging one security token for another), or are secured with an explicitchallenge/response or other negotiation protocol (when the requestor does not have aWS security token yet). The Web Service Security framework can in fact support anytype of security token. However, security tokens that are to be used across differentdomains should be interoperable. The following tokens are currently standardizedand explicitly supported: username/password combinations and X.509 certificates;binary security tokens, such as Kerberos tickets; and XML security tokens, such asSAML assertions and XrML tokens.

• WS-Policy. WS-Policy [7] provides a framework that allows Web Services to describeand communicate (publish) their policies to Web Service requestors. A policy is acollection of one or more policy assertions. Some assertions specify traditional re-quirements and capabilities such as authentication scheme and transport protocolselection. Other assertions specify requirements and capabilities that have no wiremanifestation, yet are critical to proper service selection and usage (e.g., privacypolicy, QoS characteristics). WS-Policy provides a single policy grammar to allowboth kinds of assertions to be reasoned about in a consistent manner.

• WS-SecurityPolicy. WS-SecurityPolicy [9] is an addendum to WS-Security andspecifies the policy assertions for WS-Policy which apply to WS-Security. WS-SecurityPolicy currently supports the following security policy assertions:

– What kind of SecurityToken is required, from whom, and which claims it shouldprovide.

– Integrity protection: it is possible to indicate that specific portions of a messagebe signed and that specific algorithms and keys be used and/or to indicate a set ofrequired claims (assertions) for a signature that are independent of token type orauthority.

– Confidentiality protection: WS-Policy allows to specify different confidentialitycombinations or confidentiality and integrity combinations, or even choices ofalgorithms.

– Visibility: it is possible to indicate the portions of a message that must be processedeither by an intermediary or by an endpoint, that is, what portion of a message either


needs to be passed in the clear (unencrypted), or if there must be an encryptionbinding for the intermediary.

– Specific behaviors of the 〈SecurityHeader〉.– Maximum allowed 〈MessageAge〉: this attribute specifies the actual maximum age

timeout for a message expressed in seconds.

• WS-SecureConversation. WS-SecureConversation [15] defines extensions to WS-Security and to WS-Trust to provide secure conversation across one or more messages.Specifically, this specification defines mechanisms for establishing and sharing se-curity contexts, and deriving keys from established security contexts (or any sharedsecret). The security context is defined as a new WS-Security token type that isobtained using a binding of WS-Trust.

• WS-Federation. WS-Federation [14] describes how to manage and broker trust re-lationships in a heterogeneous federated environment including support for federatedidentities, attributes, and pseudonyms. A federation consists of multiple Web Ser-vices domains, each with their own Security Token Service–STS–, and with theirown security policy. WS-Federation specifies scenarios using WS-Trust, for exampleto allow requesters from one domain to obtain security tokens in the other domainand subsequently to get access to the services in the other domain. Additionally,mechanisms are defined for single sign-in and sign-out, sharing of attributes based onauthorization and privacy policies, and integrated processing of pseudonyms (aliasesused at different sites/federations).

• WS-Privacy. WS-Privacy, as described in [11], will describe a model for embeddinginto WS-Policy descriptions a privacy language able to express preferences andorganizational privacy practice statements, and for using WS-Security to associateprivacy claims with a message. Moreover, this specification will describe howWS-Trust mechanisms can be used to evaluate these privacy claims for both userpreferences and organizational practice claims. IBM released the Enterprise PrivacyAuthorization Language (EPAL) Version 1.1 [Release 1.83] [4] specification,defining an interoperability language for exchanging privacy policy in a structuredformat between applications or enterprises. EPAL is designed as a formal languageto specify fine-grained enterprise privacy policies. It concentrates on the core privacyauthorization while abstracting from all deployment details such as data modelor user-authentication. The Platform for Privacy Preferences (P3P) specificationreleased by the World Wide Web Consortium in April 2002 supports the commu-nication of privacy policies from business applications to consumer applications.EPAL goes one step further, providing an XML language that enables organizationsto enforce P3P policies behind the Web, among applications and databases.

• WS-Authorization. WS-Authorization [12] will describe how to manage autho-rization data and authorization policies. This specification will describe how accesspolicies for a Web service are specified and managed. In particular, it will describehow claims may be specified within security tokens and how these claims will be in-terpreted at the endpoint. This specification will focus on flexibility and extensibilitywith respect to both authorization format and authorization language.

• WS-ReliableMessaging. WS-ReliableMessaging [13] defines a messaging protocolto identify, track, and manage the reliable delivery of messages between exactly twoparties, a source and a destination, in the presence of software component, system,

148 BERTINO ET AL.

or network failures. The interoperable protocol defined by WS-ReliableMessagingprovides application source and destinations a guarantee that a message that is sentwill be delivered (delivery assurance).

It is important to notice that current standardization efforts presented above, like theones in the areas of XML, SOAP, and WS-Security, were designed to interoperate, inorder to address most of the security requirements posed by Web Services.

As far as standard access control policies are concerned, the eXtensible Access ControlMarkup Language (XACML) [16] is an XML specification for defining access controlpolicies for information access over the Internet, developed by the Organization forthe Advancement of Structured Information Standards (OASIS). It became a standardin 2003. XACML is designed to support the definition of security policies that canbe shared across different applications in a distributed environment. XACML providesa standard for expressing authorization and entitlement policies, which can be sharedby heterogeneous security systems. The XACML policy language is based on XML.In addition to policy language, XACML specifies a request and response protocol fordescribing queries about a particular request and decisions made regarding the request(responses). A typical XACML usage scenario is: a subject (e.g. person, workstation)wants to access a protected resource. Access to this resource is controlled by a PolicyEnforcement Point (PEP). When the subject makes a resource request, the PEP re-formalize the request using the XACML request language describing the requester,action, resource and other relevant information, and sends it to a Policy Decision Point(PDP) for making the authorization decision. PDP will fetch the applicable policies,which are written in the XACML policy language from a policy store and determinethe authorization decision according to the XACML rules for evaluating policies. Theauthorization decision response will be expressed using the XACML response languageand deliver the decision to the PEP, which can then permit or deny access to the requester.However, XACML is not composable with the Web Service Security standard stack. Onthe other side, a comprehensive standard solution dealing with access control policies forWS services (WS-Authorization) and fully composable with the Web Service Securitystandard stack is still under development. Indeed, although several efforts have beendone to support security for web services, there is still lack of adaptive use controlmodels that can capture the dynamically changing security requirements of the targetenterprises. A further problem related with Web Services security is represented by thelack of mechanisms for preserving privacy of the users. Ws-Privacy is just mentionedin the Web Service security stack and it still has to be developed.

Finally, another important issue that is often overlooked and need to be taken careregards the lack of protocols supporting service compositions. Indeed, to meet therequirements of real-world applications one often needs to combine several differentservices at application level. Also, a service may need to invoke other services as partof its implementation. Approaches to the problem of secure service composition varydepending on application requirements and on the security policies associated with thevarious services and thus flexible solutions are required.

In the next section we address the issue of access control for web services. We proposean attribute based access control system, referred to as Ws-AC, having negotiationcapabilities for web service parameters. Our model is a first concrete effort toward asolution for regulating in a flexible and adaptive way access of web services. In order


to be as flexible as possible the system is implementation independent and can thusfunction with any specific web service technology. In addition, it is compliant withthe existing standards for security for web services. Indeed, as discussed in Section 5access control policies describing the conditions required to grant access to services arerepresented using Ws-Policy.

3. The Ws-AC model

In this section we formally present the Ws-AC model. The presentation is as follows.First, we introduce the notion of IdsTable, clusters, scripts and context tables that arepart of our solution to web service access control. Then, we formally define accesscontrol policies. The presentation is given by referring to the example of a web server,called MusicNow, transmitting mp3 files through the web at different bitrate. The webserver manages a web service, providing a service called PlaySong, for playing songsat different bitrates, and uses Ws-AC as access control system.

3.1. Preliminary definitions

In Ws-AC a service s is treated as a remote procedure to be invoked according toa set of parameters. The set of parameters characterizing the service is referred to asWSParSet. The structure of a WSParSet is {(P1, domainP1), . . . ,(Pn, domainPn)}, where(Pi, domainPi), i ∈ [1, n], is a parameter, having Pi as name and domainPi as domain.3

A tuple of parameters is a subset of the parameter names in WSParSet of the form[Pj1, . . . , Pjk] (j ∈ [1, n]; k ≤ n).

The domain of a tuple of parameters is defined as the cartesian product of thedomain of each of the parameters in the tuple, that is, domainPj1 × · · · × domainPjk.A tuple of parameters [Pj1, . . . , Pjk] is associated with a corresponding tuple of values(p1, . . . , pk) extracted by the parameters set domain. To ease the presentation, in whatfollows we represent the domain of WSParSet as a relation, according to the notionof relation of the relational data model. Semantically, a parameter of a web servicespecifies the condition under which the service can be invoked. These can regard theservice features or the quality that can be provided for the service. For instance, in thePlaySong web service above mentioned, a QoS parameter is the bitrate, whereas thesong and the corresponding performer are proper service parameters to be specifiedwhen customizing the service invocation.

The parameters of a service are often related with each other: the value of oneparameter can reduce the acceptable values of other parameters of the WSParSet. Torepresent legal combinations of parameters, parameters are expressed by means ofclusters. Precisely, a cluster is modeled as a pair composed by a parameter tuple, namedcluster name and a relation name, representing the domain of the tuple. We report theformal definition in what follows.

Definition 3.1 (Cluster). Let WSParSet be a set of parameters of a Web Service s ofthe form WSParSet = {(P1, domainP1 ), . . . , (Pn, domainPn )}, where (Pi, domainPi ) is aparameter of s. A cluster is a data structure of the form clusterName:R, where:• clusterName = 〈Pj1, . . . , Pjk〉 ( j ∈ [1, n]; k ≤ n) is a set of parameter names in

WSParSet;

150 BERTINO ET AL.

• R is the relation name representing the restricted domain of clusterName, that is R⊆ domainPj1

× · · · × domainPjk.

As introduced, a cluster, in general, is used to define the combination of parameter valuesthat can be accepted as input upon the service invocation. Note that a cluster name canalso be composed by a single parameter name. For sake of simplicity, we assume thatparameter names in a WSParSet of a service are unique.

Example 1 Consider the following parameters of the PlaySong service.(Perfomer, {“Madonna”,“Lanny Kravitz”})(Album, {“The Immaculate Collection”, “Five”})(Song, {“Vogue”, “Fly Away”})(Bitrate, [64, 256])Suppose that the songs can be played with a bitrate ranging between 64 and 256.

Intuitively, parameters [Performer, Album, Song] cannot assume all the values in theirdomain. Some combination of parameter values, indeed, do not correspond to an existingsong. Consider, for instance, the following songs possessed by MusicNow:

1. (“Madonna”, “The Immaculate Collection”, “Vogue”) 2. (“Lenny Kravitz”, “Five”,“Fly Away”)

Parameters [Perfomer, Album, Song] denote cluster: [Perfomer, Album, Song]:R1,where R1 represents the name of the relation representing the legal values for thementioned parameters. Precisely, R1={(“Madonna”, “The Immaculate Collection”,“Vogue”), (“Lenny Kravitz”, “Five”, “Fly Away”)}. The QoS Bitrate parameter, in-stead, is independent from the others. As such it is candidate to be a cluster by itself[Bitrate]:R2, where R2= {64, 65, . . . , 256}.

A service invocation in Ws-AC is formalized as an access request. Formally, wemodel an access request [2] as a tuple acc=〈 a, s, p〉 where:

• a = [A1 : a1, . . . , An : an], where Ai is a subject attribute and ai is an associatedvalue;

• s is a service identifier, i = 1, . . . , n;• p = [P1 : p1, . . . , Pk : pk] where Pi is a parameter of service s and pi, is a value

compatible with the domain of Pi i = 1, . . . , k.

Upon receiving an access request, the Ws-AC system controls whether it is possibleto grant the request, or if a negotiation has to be activated. Operatively, as soon as theaccess request is received, the system creates a new entry in a special purpose table,referred to as IdsTable, which keeps track of the received access requests and resourcesallocated to them. Then, during the eventual negotiation, the system always refers to suchentries (and associated Id) to verify messages exchange validity. Generally speaking, anegotiation in Ws-AC occurs when the parameters specified within an access requestare not acceptable by the server. We further elaborate on this aspect in Section 6.2. Inorder to negotiate services access control, and formulate adequate counterproposals tobe sent to the requesting subject Ws-AC makes use of specific rules traced in the policiesgoverning access to services. As such, before being able to introduce our access controlpolicy language we need to specify structure and semantic of the mentioned rules and


Figure 2. Context table of listening ratings

parameters. First, we need to introduce the notion of context table. A context table isa table collecting information related with the service and its quality of service. Thecontext table can be used for keeping track a variety of data, for instance the accessrequests received, the number of users connected to the system, the quality of serviceof the service to be provided. Such table is dynamically updated each time an accessrequest is received or the context changes.

Example 2 An example of context table in our scenario is given by the listening ratingsof the songs. Such relation keeps tracks of the number of times a song has been requiredby the clients. Another example of context table is given by the average bitrate of a user,obtained as an average of the bitrates of all the songs that a user has listened until thatmoment. Figure 2 shows the context table “listening ratings”. Such table is referred toas CT1 and its signature is CT1(Performer, Album, Song, Rate).4

Figure 3 shows a table representing the “average bitrate”. The name of the contexttable is CT2 and it has the following structure CT2(UserId, AverageBitrate).

To dynamically determine the best values to propose during a negotiation, we make useof particular queries on the context tables. In the following we refer to such type ofqueries as scripts.

Example 3 With respect to the context tables of Example 2 consider the followingscripts: Script1() = �Song(σ Performer = “Madonna" AND ListeningRatings > 10000(CT1))

Script2() = �AverageBitrate(σ UserId = 0x1234(CT2))Script3(name) = �Song(σ Performer = [name] AND ListeningRatings > 10000(CT1))Script1 provides the titles of the songs of performer Madonna having a listen-

ing rating greater than 10000. Script2, instead, returns the average bitrate value ofthe user identified by id 0x1234. Finally, Script3 is the parameterized version ofScript1.

Having introduced the notions of context table and script we can now define anegotiation trigger. A negotiation trigger is a rule that, when active, automatically bindsthe parameter names of a cluster either with a tuple of values or with a script. Dependingupon the type of binding, we classify negotiation triggers as static or dynamic. A static

Figure 3. Context table “listening average bitrate”

152 BERTINO ET AL.

trigger associates a cluster with a constant tuple of values, conveyed in the trigger itself.A dynamic trigger, instead, associates a cluster with a script. In such case the values tobe associated with the cluster are determined upon the execution of the script.

Further, if the associated script does not convey any parameter, the trigger is said sim-ple, otherwise it is said parametric. Note that, in case of dynamic triggers, the output ofa script can also eventually be empty, which implies that a legal tuple of values cannot befound and the negotiation has to be aborted. We formalize the notion of negotiation trig-ger in the following definition. In the definition, Out(X) denotes the output of a script X.

Definition 3.2 (Negotiation trigger). Let s be a service and WSParSet the associatedset of parameters. A negotiation trigger is a tuple of the form negTrig = 〈clusterName:R,value〉 where:• clusterName is a cluster name built from the WSParSet of s;• R denotes the domain of clusterName;• value can assume one the following forms:

1. (v1, . . . , vn) is a tuple of values;2. ScriptName(ParamSet) is a signature script, where ParamSet = (P1, . . . , Pn) is a

(possible empty) set of parameter names of the script.The following conditions have to be satisfied:

• if value is of the form (v1, . . . , vn), then (v1, . . . , vn) ∈ R, and the component R isomitted,

• if value is of the form ScriptName(ParamSet):

1. Out(ScriptName(ParamSet)) ⊆ eq R;2. ∀ Pi (i=1, . . . , n) ∈ ParamSet ∃ Pk ∈ clusterName : Pi = Pk (k ∈ [1, . . . ,

|clusterName|]).

Example 4 With reference to PlaySong service, consider the following clusters:[Performer, Album, Song]:R1

[Bitrate]:R2

where R1= {(“Madonna", “The Immaculate Collection”, “Vogue”), (“Lenny Kravitz”,“Five”, “Fly Away”)} and R2= {64, 65, . . . , 256}. With respect to context tables ofExample 2 consider now the following scripts:

Script1() = �Perfomer, Album, Song(σ Performer = “Madonna′′ AND ListeningRatings > 10000(CT1))Script2() = �AverageBitrate(σ UserId = 0x1234(CT2))Script3(name) = �Perfomer, Album, Song(σ Performer = [name] AND ListeningRatings > 10000(CT1))Example of static triggers are:negT1 = 〈 [Perfomer, Album, Song], (“Lenny Kravitz”, “Five”, “Fly Away”) 〉negT2 = 〈 [Bitrate], (128) 〉negT1 returns (“Lenny Kravitz”, “Five”, “Fly Away”). negT2 returns the value 128.Dynamic triggers are:negT3 = 〈 [Perfomer, Album, Song]:R1, script1() 〉negT4 = 〈 [Bitrate]:R2, Script2() 〉negT5 = 〈 [Performer, Album, Song]:R1, Script3(Performer) 〉

negT3 returns a set of tuples conveying the name of the performer, the name of thealbum and the name of the song. In particular, such tuples correspond to Madonna’ssong having a listening rating greater than 10000. negT4 returns a tuple5 conveying


the average bitrate of user whose identifier is 0x1234. Finally, trigger negT5 is theparametrized version of trigger negT3.

3.2. Ws-AC access control policies

An access control policy in Ws-AC is composed of three main components: a componentto authenticate the requester by verifying its attributes, a component for specifying thelegal parameter values for the referred service, and a component for supporting thenegotiation. We have already defined negotiation triggers, to be used for specifying thecomponent related with negotiation. Next, we define attribute conditions [2], specifiedwithin an access control policy for verifying service requestor properties.

Definition 3.3 (Attribute Condition). Let Attr be an attribute. An attribute conditionC is an expression of the form A op k where:

• A denotes the attribute name;• op is a comparison operator, such as =, <, >, =, ≤, ≥ ;• k is a constant, compatible with the domain of A.

We are now ready to define an access control policy.

Definition 3.4 (Access control policy). Let s be a service. An access control policypol is a tuple of the form pol = 〈 s; ClusterSet; NegTSet; C 〉 , where:

• s is the service identifier;• ClusterSet = {clusterName1:R1, . . . , clusterNamen:Rn} where clusterNamei:Ri (i =

1, . . . , n) is a cluster of s defined according to Definition 3.1;• NegTSet = {negT1, . . . , negTk} (k ≥ 0) is an optional set of negotiation triggers

defined according to Definition 3.2;• C is a set of attribute conditions {C1, . . . , Cn}, where Ci (i = 1, . . . , n) is defined

according to Definition 3.3.

An access control policy is said to be dynamic if the NegTSet component is not null, itis said to be static otherwise.

Example 5 The access control policy:pol1 = 〈PlaySong; {[Perfomer, Album, Song]:R1, [Bitrate]:R2}; {negT1, negT2};

{Subscription = Gold, DateOfBirth < 1986} 〉 where:

• negT1 = 〈 [Perfomer, Album, Song]:R1, Script1(Performer) 〉• negT2 = 〈 [Perfomer, Album, Song]:R1, Script2() 〉• Script1(name) = �Performer, Album, Song(σ Performer = [name] AND ListeningRating > 10000(CT1))• Script2() = �Perfomer, Album, Song(σ Performer = “Madonna” AND ListeningRating > 10000(CT1))• R1={(“Madonna”, “The Immaculate Collection”, “Vogue”),(“Lenny Kravitz”,

“Five”, “Fly Away”)}• R2= {64, 65, . . . , 256}• CT1 is the context parameter reported in Figure 2

154 BERTINO ET AL.

is an example of dynamic access control policy, stating that a Madonna’s or LennyKravitz’s song can be played with a bitrate ranging from 64 to 256 by subjects with asubscription of type Gold older than 18.

Negotiation triggers have to be carefully associated with dynamic access controlpolicies. Each negotiation trigger controls a cluster of the ClusterSet and it is possibleto associate with each cluster at most three negotiation triggers, each of a differenttype (static, dynamic parametric and dynamic simple). Ws-AC assigns by default adifferent priority to the trigger execution. Higher priority is always given to the dynamicparametric trigger, since it is the one that better meets user requests. Input parameters,indeed, are used in the script execution to determine one or more cluster tuples as similaras possible to those specified in the original request. If the execution of such triggerfails, the dynamic simple trigger is then activated, followed by the static one.

As such, access control policies have to be properly defined in order to be enforced.Policies specifying a wrong number of triggers might cause inconsistencies and causesecurity breaches, making access requests not decidable. Based on the above considera-tions, we need to restrict the admitted policies in those being well formed. The conditionsfor well formed policies are given in the following definition.

Definition 3.5 (Well formed policy). Let pol be an access control policy definedaccording to Definition 3.4. pol is a well formed access control policy if the followingconditions hold:

1. ∀ clusterNamei (i = 1, . . . , n) ∈ ClusterSet,∀ clusterNamej (j = 1, . . . , k) ∈ ClusterSet:i =j , clusterNamei∩ clusterNamej = Ø, h = 1, . . . , n;

2. ∀ negTi ∈ NegTSet (i = 1, . . . , t), negTi.clusterNamei:Ri ∈ ClusterSet;3. ∀ clusterNamei:Ri ∈ ClusterSet there are at most three negotiation triggers, each of

a different type.

In the following, we always refer to well formed policies, unless stated otherwise.The first condition in the above definition requires the clusters in a ClusterSet to bedisjoint, that is, the same parameter names cannot appear in two different clusters.The second condition states that each negotiation trigger controls a cluster appearingin the ClusterSet of the policy. Finally, the third condition requires each cluster of theClusterSet to be associated with at most three triggers, each of a different type.

Example 6 With reference to the Example 1, consider the following static accesscontrol policies:

1. pol1 = 〈PlaySong; {[Performer, Album, Song]:R1, [Bitrate]:R2}; {Subscription =Gold, DateOfBirth < 1986} 〉

2. pol2 = 〈PlaySong; {[Performer, Album, Song]:R1, [Performer, Bitrate]:R2};{Subscription = Gold, DateOfBirth < 1986} 〉


Figure 4. Normal form schema of a policy according to Ws-Policy

Further, suppose that R1 and R2 convey the following tuple of values:

R1={(“Madonna”, “The Immaculate Collection”, “Vogue”), (“Lenny Kravitz”, “Five”,“Fly Away”)}R2 = {64, 65, . . . , 256}

Policy pol1 states that PlaySong can be invoked by a subject older than 18, holding asubscription of type Gold. The available songs are recorded in the relation named R1.Such songs can be played at the bitrates shown in R2. Note that policy pol1 is wellformed. By contrast, policy pol2 is an example of not well formed policy since theclusters of the ClusterSet share a parameter.

3.3. Specifying Ws-AC policies using WS-Policy

Ws-AC access control policies can be implemented in a format compliant to WS-Policy[7], the current standard for Web service policy specification. Ws-Policy is a specificationthat defines a general framework to describe a broad range of Web service policies. Ws-Policy defines a policy as a collection of alternatives. Each alternative is a collection ofassertions. Generally speaking, a policy assertion represents an individual requirement,a capability etc. For instance a policy assertion can specify a particular authenticationscheme, a transport protocol selection, a privacy policy, QoS characteristic etc. Thenormal form schema of a policy according to Ws-Policy is shown in Figure 4. In thisschema, * indicates 0 or more, [] indicates that the contained items have to be treated asa group.

The 〈wsp:Policy〉 element is used as a policy container. The〈wsp:ExactlyOne〉 element is used to define a collection of policy alterna-tives. The 〈wsp:All〉 element instead is used to define a collection of policiesassertions each of which must be satisfied. A policy alternative can be considered as aparticular scheme of interaction that the requester of the service must be able to satisfy.Note that a requester can choose only a single policy alternative among the alternativespresented by the policy. Moreover if a policy alternative is chosen, the requester mustbe able to satisfy all the policy assertions included in that policy alternative.

Figure 5 reports an example of policy that adheres to Ws-Policy specification.6 Thisexample, taken from [7], shows two policy alternatives, each composed by a single policyassertion. The policy has to be interpreted in the following way: if the first alternative isselected, only the Kerberos token type is supported; conversely, if the second alternativeis selected, only the X.509 token type is supported.

The assertions used in a policy expression can be defined in public specifications, likeWs-SecurityPolicy, Ws-PolicyAssertion, or they can be defined by the entity owning the

156 BERTINO ET AL.

Figure 5. Example of policy

Figure 6. XML elements used to implement policy assertions

web service. The assertions of the first type are named standard assertions and they areunderstandable potentially from any client. The assertions defined by the entity owningthe Web service instead can be understood only from those clients to whom the entityhas already released the specifications.

To encode Ws-AC access control policies we define a new type of policy assertions,since no public specification we are aware of define assertions suitable for expressingattribute conditions and parameter conditions (cluster and cluster domain) required byWs-AC policy formalism (see Definition 3.4).

The policy components suitable to be represented as policy assertions are: the set ofclusters (ClusterSet component) and the attribute conditions (C component) of a Ws-AC policy. The NegTSet component is excluded since it conveys information neededby the system and thus there is no need to publish it to clients. Finally, the service namecomponent is excluded because it will be used as unique identifier, as described later inthis section.

The XML elements used to implement the policy assertions are reported in Figure 6.In the figure, + indicates one or more.

Example 7 Consider the following Ws-AC policy:pol1 = 〈PlaySong; {[Performer, Album, Song]:R1;[Bitrate]:R2}; {negT1,negT2};{Subscription = Gold; DateOfBirth < 1986}〉where R1={(“Madonna”, “The Immaculate Collection”, “Vogue”), (“Lenny Kravitz”,“Five”, “Fly Away”)} and R2= {64, 65, . . . , 256}. The representation of pol1 in a formatcompliant to Ws-Policy is reported in figure 7.


Figure 7. Ws-AC policy represented in a Ws-Policy compliant format

Algorithm 1 formalizes the necessary steps to represent one or more Ws-AC policies ina format Ws-Policy compliant. Basically, the task of the algorithm is to merge all theWs-AC policies attached to the same service into a single Ws-Policy compliant policy.Precisely, given a service name, each Ws-AC policy referring that service becomes apolicy alternative. The client can choose one alternative among the alternatives providedby the policy. Note that since all the Ws-AC policies referring the same service aremerged into a single policy conforming to Ws-Policy, such policy can be uniquelyidentified by the service name (see for instance Example 7).

Function AttributeName(ci) extracts the name of the identity attributes appearing incondition ci. Function Condition(ci), instead, extracts the corresponding condition (e.g.,consider condition c1 = DateOfBirth < 1986. AttributeName(c1) returns “DateOfBirth,”whereas Condition(c1) instead returns “ < 1986”).

Example 8 Consider the following Ws-AC policies:pol1 = 〈PlaySong; {[Performer, Album, Song]:R1} ; {NegT1, NegT2} ; {Subscription= Gold, DateOfBirth > 1986} 〉pol2 = 〈PlaySong; {[Bitrate]:R2}; {NegT3, NegT4, NegT5}; {DateOfBirth > 1986,Subscription = Gold}〉pol3 = 〈TuningService; {[Bass,Treble]:R3}; {NegT6, NegT7}; {Subscription =Premium}〉

158 BERTINO ET AL.

where R1 and R2 have been introduced in Example 6 and R3= {{4.0, 5.0}, {4.1, 4.9},{4.2, 4.8}, {4.3, 4.7}, {4.4, 4.6}, {4.5, 4.5}}Pol1 and pol2 are both related with “PlaySong” service. Pol3, instead, controls accessto the service “TuningService”. These three policies, according to Algorithm 1, aretranslated in two Ws-Policy compliant policies. The result is shown in Figure 8. Notethat the represented Ws-Policy compliant policy can alternatively be expressed in a morecompact form. However, for the sake of simplicity we adopt the normal form describedin Ws-Policy specifications.

4. Enforcement and negotiation of access control policies

In this section we discuss how access control policies are enforced in Ws-AC. First, weprovide the criteria adopted for establishing whether an access request is either accepted,denied or negotiated. Then, we focus on the conditions under which an access requestcan be negotiated and in Section 4.2 we detail the protocol underlying a negotiation inWs-AC.

4.1. Satisfying an access control policy in Ws-AC

As mentioned before, as soon as an access request is received, it is evaluated with respectto the policies specified for the required service. First, the access request has to complywith at least a policy.


Figure 8. Ws-AC policy expressed in Ws-Policy

160 BERTINO ET AL.

Definition 4.1 (Policy compliance). Let acc=〈 a, s,p〉 be an access request, and letpol be an access control policy of the form pol = 〈 s, ClusterSet, negTset, C〉. acccomplies with pol if both the following conditions hold:• acc.s = pol.s;• for each attribute condition C of the form C = A op k, C ∈ pol.C; ∃ j : A = acc.a.Aj

∧ C is true according to value acc.a.aj assigned to A.

As stated by the definition, an access request for a certain service s is compliant witha policy defined for the same service if the list of attribute conditions specified in thepolicy are all evaluated true, according to the attributes sent together with the accessrequest. By contrast, an access request is always rejected if the access request doesnot comply with any of the existing policies for the requested service. Note that theconcept of compliance does not deal with the parameters used to specify access request.Indeed, parameter evaluation will be used to establish whether a full authorization maybe granted, as specified in the following definitions.

Definition 4.2 (Full acceptance). Let acc=〈 a, s, p〉 be an access request and pol be apolicy of the form pol = 〈 s, ClusterSet, NegTset, C〉. We say that acc is fully acceptedby pol if the following conditions hold:1. acc is compliant with pol according with Definition 4.1;2. |acc.p| = |ClusterParamSet|, where ClusterParamSet = {∪ pol. ClusterSet.

clusterNamei.Pk (i=1, . . . ,|ClusterSet|; k=1, . . . ,|clusterNamei|)};3. ∀ clusterNamei:Ri (i=1, . . . , n) ∈ ClusterSet, ∃ (Pj1: pj1, . . . , Pjk: pjk) ∈ acc.p:

(Pj1, . . . , Pjk) ≡ clusterNamei ∧ (pj1, . . . , pjk) ∈ Ri.

A full acceptance is thus granted if the parameters appearing in the access request areall and only the parameters specified in the policy, and their value is compatible withthe values admitted by the policy.

Example 9 Consider the well formed access control policy presented in Example 5,and the following access requests:

acc1 = 〈 Subscription:Gold, DateOfBirth: 1977; PlaySong; Perfomer: “Madonna”, Al-bum: “The Immaculate Collection”, Song: “Vogue”, Bitrate: 128 〉acc2= 〈 Subscription:Gold, DateOfBirth: 1978; PlaySong; Performer: “Madonna”, Al-bum: “The Immaculate Collection” 〉acc3= 〈 Subscription:Gold, DateOfBirth: 1970; PlaySong; Performer: “Madonna”, Al-bum: “True Blue”, Song: “Jimmy Jimmy”, Bitrate: 128 〉

The above access requests are all compliant with pol1. However, acc1 is the only onefully accepted. acc2 indeed specifies a wrong number of parameters whereas acc3 hasthe correct number of parameters, but the tuple of values (“Madonna”, “True Blue”,“Jimmy Jimmy”) does not belong to domain R1 of cluster [Performer, Album, Song].

An access request is not fully acceptable by a policy and may be negotiated if one ofthe following conditions hold:


• access request and policy are specified using a different set of parameters;• one or more clusters appearing in the policy do not have a corresponding tuple of

parameter values in the access request.

Note that a negotiation process is feasible if, in addition to the condition of above, theNegTSet component of the policy with respect to which the access request is compliantis not empty. Each trigger of a NegTset controls a cluster of the policy. A negotiationtrigger is activated when the associated cluster is not well specified in the access request,that is, some parameters of the cluster are missing or their values are outside the domainspecified in the policies. Note that it is not required for all the clusters listed in thepolicy to be controlled by any negotiation trigger. We say that the clusters not associatedwith any trigger are non-negotiable, as their value cannot be negotiated by the parties.As a result, if an access request is compliant with the policy but it cannot be acceptedbecause of a non negotiable cluster, the access request is rejected. Otherwise, if theaccess request is compliant and the incorrect parameters are controlled by negotiationtriggers, the negotiation starts, and we say that the access request is partially accepted.

Example 10 Consider the following access control policy:pol1= 〈PlaySong; {[Performer, Album, Song]:R1, [Bitrate]:R2}; {negT1, negT2};{Subscription = Gold, DateOfBirth < 1986}〉negT1 = 〈[Perfomer, Album, Song]:R1, Script1()〉negT2 = 〈[Bitrate]:R2, Script2()〉where R1= {(“Madonna”, “The Immaculate Collection”, “Vogue”), (“Lenny Kravitz”,“Five”, “Fly Away”)} and R2= {64, 65, . . . , 256}.

With respect to such policy the consider access request:acc1 = 〈Subscription:Gold, DateOfBirth: 1977; PlaySong; Perfomer: “Madonna”, Al-bum: “Like A Prayer”, song: “Cherish”, Bitrate: 128〉

Cluster [Performer, Album, Song]:R1 in pol1 presents a corresponding tuple of valuesin acc1 that is (“Madonna”, “Like A Prayer”, “Cherish”). However, such tuple does notbelong to the cluster domain R1. Such cluster is controlled by trigger negT1 which canbe activated to determine the counter proposal. By contrast, the value (128) specified inthe access request for cluster [Bitrate]:R2 is legal, as such trigger negT2 is not activated.

If the negotiation trigger is parametric, the values to be passed are extracted by thepartially acceptable access request and used to execute the script. Next example clarifiessuch concept.

Example 11 Consider the following access control policy:pol1= 〈 PlaySong; {[Performer, Album, Song]:R1, [Bitrate]:R2}; {negT1};{Subscription = Gold, DateOfBirth < 1986} 〉negT1 = 〈 [Perfomer, Album, Song]:R1, Script1(Performer) 〉Script1(name) = �Performer, Album, song(σ Performer = [name] AND ListeningRatings > 10000(CT1))where R1= {(“Madonna”, “The Immaculate Collection”, “Vogue”), (“Lenny Kravitz”,“Five”, “Fly Away”)}, R2= {64, 65, . . . , 256} and CT1 is the context table of Figure 2.

Consider the following access request:acc1 = 〈 Subscription:Gold, DateOfBirth: 1977; PlaySong; Perfomer: “Madonna”, Al-bum: “Like A Prayer”, song: “Cherish”, Bitrate: 128 〉

162 BERTINO ET AL.

Like in Example 9, the system executes rule negT1. Note that Script1 is charac-terized by parameter name Performer. As such the input parameter in this context is“Madonna” and the script extracts from context table CT1, the tuples of performerMadonna requested by more than 10000 users.

4.2. Negotiation of web services in Ws-AC

As introduced in previous section, access control policies enable negotiation of serviceparameters in case of access requests compliant with policies for which the wronglyspecified clusters (or missing clusters) of parameters are negotiable.

The partially accepted access request is the input to a Ws-AC component in chargeof determining a valid counterproposal for the required service. We call the messageconveying the counterproposal negotiated access proposal or NAP, for brevity. A NAP isgenerated for each policy with which the access request is compliant, and it carries, likean access request, a set of acceptable parameter values. The intent of a NAP exchange isto drive the client toward the specification of an acceptable access request for the service.Upon receiving such counterproposal the client, in turn, returns a message conveyingone selected among the received ones or it submits a new NAP. The system first verifiesthat the IdSession submitted within the NAP is related to a negotiation being currentlyexecuted.

The access control system then evaluates whether the received proposal can be ac-cepted or not. In case the proposal cannot be accepted, the system creates new NAPs,if possible, and forward them to the user. The negotiation process, as such, follows amulti-round fashion until an acceptable proposal is received, or all possible proposalshave been sent and no valid access request determined. The described steps of the nego-tiation are summarized in Appendix A, while the core of the access control algorithm issketched by Algorithm 2.

We now formalize the negotiation process, starting from the NAP message definition.

Definition 4.3 (Negotiated Access Proposal (NAP). Let acc = 〈 a; s;p 〉 be an accessrequest and let pol = 〈 s; ClusterSet; NegTSet; C 〉 be an access control policy. Let accbe compliant with pol. A Negotiated access Proposal (NAP) is a tuple of the form nap= 〈SessionId; ap, 〉 where:

• SessionId is a session identifier denoting the current negotiation;• ap = {P1:p1, . . . , Pn:pn} is a list of pairs where Pi is a parameter name and pi is the

corresponding value, (i = 1, . . . , n).

A negotiated access proposal is fully accepted by an access control policy if the SessionIdis a valid Id and refers to the correct session and the access request obtained by replacingthe parameter component p of acc with the one specified in the negotiated accessproposal is fully acceptable.

Definition 4.4 (Total acceptance of a negotiated access proposal). Let NAP =〈SessionId; ap〉 be a negotiated access proposal, originated by the partial acceptance of


access request acc = 〈 a; s;p 〉 . Let pol be a an access control policy. We say that napis fully accepted by pol if the following conditions hold:

• SessionId ∈ IdsTable;• access request acc′ = 〈 a; s;ap 〉 is fully acceptable by pol, according to Definition 4.2.

Definition 4.5 (Partial acceptance of a negotiated access proposal). Let NAP =〈SessionId; ap〉 be a negotiated access proposal generated by compliance of accessrequest acc= 〈a; s; p〉 . Let pol be an access control policy of the form pol = 〈s;ClusterSet; NegTSet; C〉 . We say that NAP is partially accepted by pol iff SessionId ∈IdsTable and the access request acc′ = 〈 a; s; ap〉 is partially acceptable.

Note that, like conventional access requests, partial acceptance of NAPs occurs onlyif the NegTset fields of the corresponding policies are not empty, since it implies thatthe negotiation can proceed. The function in charge of generating a NAP is FunctionProposalGenerator(), which accepts as input an access control policy having negoti-ation capabilities (see Section 3.2), the p component of the access request (or NAP)partially accepted by the policy, and an IdSession. The algorithm executes the followingoperations for each cluster conveyed in the policy.

164 BERTINO ET AL.

First, it extracts the corresponding tuple of values specified in the access request byuse of function ExtractValues().7 If such tuple is not properly specified the mechanismto determine the correct cluster values for the counter proposal is activated. Specifically,the negotiation triggers associated with the wrongly specified cluster(s) are selected.(For simplicity we consider the case of one single cluster in the ClusterSet in the policybeing wrongly specified). If no negotiation trigger is present for such a cluster, thenegotiation is not feasible and the access request is rejected. Otherwise the triggers areexecuted with respect to their priority. If the trigger execution does not provide correcttuple values for the associated cluster8 the process is interrupted, otherwise one of thetuples generated by the trigger execution is chosen. The selected tuple is passed tofunction ReturnTuple() which is the function in charge of composing the new NAP. Thenew NAP will be composed by all acceptable values for the ClusterSet of the policy,using the tuples correctly specified in the original access request, where possible, andusing the above algorithms to determine correct tuples for the others. This process isexecuted for all the partially accepted policies and the NAP sent to the client.

The algorithm used to generate a negotiated access proposal is Algorithm 3.

Example 12 Consider the following access control policies:pol1 = 〈PlaySong; {[Performer, Album, Song]:R1, [Bitrate]:R2}; {negT1, negT2, negT3,negT4}; {Subscription = Gold} 〉


pol2 = 〈 PlaySong; {[Performer, Album, Song]:R1}; {Subscription = Gold} 〉 where:

– negT1 = 〈[Perfomer, Album, Song]:R1, Script1(Performer) 〉– negT2 = 〈[Perfomer, Album, Song]:R1, Script2() 〉– negT3 = 〈[Perfomer, Album, Song]:R1, “Madonna",“The Immaculate Collection”,

“Vogue” 〉– negT4 = 〈 [Bitrate]:R2, 128 〉.– Script1(name) =�Performer, Album, Song(σ Performer = [name] AND ListeningRating > 10000(CT1))– Script2() = �Perfomer, Album, Song(σ Performer = “Madonna”ANDListeningRating>10000(CT1))

where R1= {(“Madonna”, “The Immaculate Collection”, “Vogue”), (“Lenny Kravitz”,“Five”, “Fly Away”)} e R2= {64, 65, . . . , 256}. CT1 is the reference to the context tableof Figure 2. Further, consider the following access request:acc1= 〈 Subscription: Gold; PlaySong; Performer: “Alanis Morisette”, Album: “Like aPrayer”, Song: “Cherish”, Bitrate: 128〉.

Upon receiving acc1 the system creates a Session id and a new entry in IdsTable.Such an access request is compliant with pol1 and pol2 and it is also partially ac-cepted by both. However, since pol2 has no triggers, it cannot activate any nego-tiation. By contrast, pol1 activates the mechanism for creating a negotiated accessproposal. acc1 has a tuple of values corresponding to cluster [Performer, Album,Song] which is not correct. As such, the negotiation triggers controlling the clusterare used. pol1 is composed of triggers negT1, negT2 negT3. The first trigger to beexecuted is the parametric one, that is, negT1. However, since there is no entry for“Alanis Morisette” in R1 the script execution fails. negT2 is then activated, and itsexecution succeeds since it returns the tuple of values (“Madonna”, “The Immacu-late Collection”, “Vogue”). Then, the value specified in the access request for clus-ter [Bitrate] is checked. Such a parameter is specified with a legal value, as suchno trigger execution is required. Finally, the following negotiated access proposal isgenerated:neg1 = 〈oxffffffff; Performer: “Madonna”, Album:“The Immaculate Collection”,Song:“Vogue”, Bitrate: 128〉Suppose now that the client replies with the following NAP:

neg2 = 〈oxffffffff; Performer: “Lenny Kravitz”, Album:“The Immaculate Collection”,Song:“Vogue”, Bitrate: 0〉

The system verifies the identity of the NAP sender by checking the IdsTable. Thenegotiation protocol proceeds and trigger negT1 is, in this case, executed. The execution

166 BERTINO ET AL.

Figure 9. Ws-AC architecture

returns the legal tuple (“Lanny Kravitz”, “Five”, “Fly Away”). With regard to [Bitrate],the access request inludes an incorrect value because such value is not included in R2. Assuch, trigger negT4 is executed and returns value 128. The system builds the followingproposal:neg3 = 〈oxffffff; Performer:“Lenny Kravitz”, Album:“Five”, Song:“Fly Away”,Bitrate:128〉 .

5. Ws-AC system architecture

In this section we briefly describe the architecture of the prototype system implementingWs-AC, shown in Figure 9. We explain the architectural role of the most importantmodules in the remaining of this section.

5.1. Message handler

The Message Handler is the module in charge of handling SOAP messages. Precisely,depending on the message content, it can receive SOAP messages of two different types.The first type of message conveys an access request, while the second type conveys anegotiated access proposal.

If the SOAP message is of the first type, the header of the message conveys oneor more attribute certificates and, eventually, an identity certificate. The MessageHandler validates the digital credentials by using the XML Validator and the ProfileDatabase storing the public key certificates most widely used. The body of the messageconveys the name of the requested service as well as parameter values for the serviceinvocation. The message name is used to check from the Service List Database whetherthe requested service is actually available.


Figure 10. Example of access request generated by the Message Handler

After the digital credentials validation and the verification of the service availabilitythe Message Handler composes an access request. Such a request is stored together witha session identifier in the IdsTable Database and sent to the Authorization Manager.Figure 10 reports an example of an access request message.

If the SOAP message is delivering a negotiated access proposal, the body of themessage conveys the IdSession and the parameter values for the service invocation.The Message Handler checks the existence of such an identifier in the IdsTable andextracts the associated access request. The parameter values of the access request arethen replaced with the parameters values extracted from the negotiated access proposalof the message. The access request is finally sent to the Authorization Manager.

5.2. Authorization manager

The main task of the Authorization Manager is to determine whether the access requestcan be fully or partially accepted or it has to be rejected. Specifically, to give such aresponse, the Authorization Manager module runs Algorithm 2.

If the access request is rejected, the Authorization Manager sends a message to theMessage Handler notifying that the access cannot be granted. The Message Handlerbuilds a proper SOAP message to be sent to the client. If the access request can be fullyaccepted, it is forwarded to the SOAP Gateway and to the Context Tables Manager.The former converts the access request in a service invocation, the latter updates theContext Tables. Finally, if the access request is partially accepted it is sent togetherwith all the related policies to the Negotiation Agent. The Negotiation Agent, in turn,creates proposals for each policy by activating the corresponding negotiation triggersby executing Algorithm 3. Such parameters value proposals are sent to the MessageHandler which builds the corresponding negotiated access proposal.

5.3. Control panel

The Control Panel is an administration module enabling the system administrator tocreate, edit and remove policies, negotiation triggers, scripts and context tables. Itis used as a front end to program the Context Tables Manager, in order to exe-cute the desired update on the Context Tables when an access request is received.

168 BERTINO ET AL.

Figure 11. Ws-AC behavior upon an access request

Finally the Control Panel provides a graphical user interface to automatically mapWs-AC policies in a Ws-Policy compliant format. The policies represented in sucha format can be published into UDDI registries for being read by any potentialclient.


Figure 12. Ws-AC negotiation

6. Conclusion

Although several research and standardization efforts have been recently undertaken toaddress web services security, there are still a number of open issues to be addressed.In particular, access control and privacy represent the most significant aspects still tobe addressed. In this paper we have proposed Ws-AC, an innovative, implementation-independent, approach to access control. The model is characterized by a number ofkey features, including identity attributes and service negotiation capabilities. In thepaper we have formally defined the protocol for carrying on negotiations, by specifyingthe types of message to be exchanged and their contents, based on which requestor and

170 BERTINO ET AL.

provider can reach an agreement about security requirements and services. We have alsodiscussed the architecture of the prototype we are currently implementing. As part ofthe architecture we have proposed a mechanism for mapping our policies onto the WS-Policy standard which provides a standardized grammar for expressing Web servicespolicies. To the best of our knowledge this is the first model proposed with such features.As future work we plan to further explore the possibility of integrating our model withexisting standards. In particular, the possibility of exploiting XACML still has to beanalyzed. Further, since this aspect is still missing in the Ws-Security stack, we wouldlike to integrate our model with mechanisms for supporting privacy of the users, to allowclients to confidently send private credentials to unknown services. A prototype of theWs-AC is under development by a Java platform and Apache Tomcat web server.

A. The negotiation flow

Figures 11 and 12 sketch the flow of operations of the Ws-AC negotiation protocol.

Acknowledgments

This work was partially funded by the Information Society Technologies programme ofthe European Commission under the IST-2002-01945 TrustCoM project (2004-2006).

Notes

1. By Identity attributes we refer to properties that can be associated with users, like name, birth-date, creditcards.

2. In this context, by trusted users we mean subjects whose associated attributes have been validated by theserver.

3. A domain domainPi is specified either by enumerating its legal values {p1, . . . , pn} or by using a range[pbegin,pend].

4. The primary key is given by Performer, Album and Song.5. The output is given by one one single tuple because UserId is primary key of context table CT2.6. The XML namespace URI to be used for implementating policies using the Ws-Policy specification

is http://schemas.xmlsoap.org/ws/2004/09/policy Moreover the following namespaces have been usedin the example: wsse http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsdhttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd\\wsphttp://schemas.xmlsoap.org/ws/2004/09/policy

7. We do not report ExtractValues() algorithm since it is trivial.8. Note that this case is possible only if no static triggers are present.

References

[1] B. Atkinson et al., Web services security (ws-security), April 2002.[2] E. Bertino, A. C. Squicciarini, and D. Mevi, “A fine-grained access control model for Web services,” in

IEEE International Conference on Services Computing (SCC 2004), Shanghai, Sept. 2004.[3] D. Box et al., Simple Object Access Protocol (SOAP) 1.1, Technical Report W3C, 2000.[4] The Enterprise Privacy Authorization Language (EPAL 1.1)., http://www.zurich.ibm.com/security/

enterprise-privacy/epal/[5] Liberty Alliance Project, http://www.projectliberty.org/


[6] Advancing SAML, an XML-based security standard for exchanging authnetication and authorizationinformation. http://www.oasis-open.org/ committees/security.

[7] Web Service Policy Framework (Ws-Policy), September 2004. http://www.106.ibm.com/developerworks/library/specification/ws-polfram/

[8] IBM, Microsoft, RSA, VeriSign. web services Trust Language (WS-Trust). Version 1.0. December 18,2002., http://msdn.microsoft.com/webservices/?pull=/library/en-us/dnglobspec/html/ws-trust.asp.

[9] IBM, Microsoft, RSA, VeriSign. web services Security Policy Language (WS-SecurityPolicy). Version1.0. December 18, 2002. http://msdn.microsoft.com/webservices/?pull=/library/en-us/dnglobspec/html/ws-securitypolicy.asp.

[10] IBM and Microsoft. Security in a web services World: A Proposed Architecture andRoadmap. April 2002. http://msdn.microsoft.com/webservices/?pull=/library/en-us/dnwssecur/html/securitywhitepaper.asp

[11] Security in a web services World: A Proposed Architecture and Roadmap. http://www-106.ibm.com/developerworks/webservices/library/ws-secmap/

[12] WS-Authorization. http://xml.coverpages.org/ni2002-04-11-b.html[13] Web Services Reliable Messaging Protocol (WS-ReliableMessaging). March 2004. http://msdn.

microsoft. com/ws/2004/03/ws-reliablemessaging/[14] IBM, Microsoft, RSA, VeriSign. web services Federation Language (WS-Federation). Version

1.0. July 8 2003. http://msdn.microsoft.com/webservices/?pull=/library/en-us/dnglobspec/html/ws-federation.asp.

[15] IBM, Microsoft, RSA, VeriSign. web services Secure Conversation Language (WS-SecureConversation).Version 1.0. December 18, 2002. http://msdn.microsoft.com/webservices/?pull=/library/en-us/dnglobspec/html/ws-secureconversation.asp

[16] OASIS eXtensible Access Control Markup Language 2 (XACML) Version 2.0. Committee draft 02, 30Sep 2004 http://docs.oasis-open.org/xacml/access control-xacml-2.0-core-spec-cd-02.pdf

cerias tech report 2005-98 ws-ac: a fine grained access

Documents