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, 2006 c 2006 Springer Science + Business Media, LLC. Manufactured in The Netherlands. DOI: 10.1007/s11280-005-3045-4
Ws-AC: A Fine Grained Access Control System for Web Services ELISA BERTINO
[email protected] Computer Sciences Department and CERIAS, Purdue University, West Lafayette ANNA C. SQUICCIARINI IVAN PALOSCIA LORENZO MARTINO Dipartimento di Informatica e Comunicazione, Universita’ degli Studi di Milano
[email protected] [email protected] [email protected]
Published online: 20 September 2005
Abstract The emerging Web service technology has enabled the development of Internet-based applications that integrate 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 complex Web applications, several security issues still need to be addressed. Among the various open issues concerning security, an important issue is represented by the development of suitable access control models, able to restrict access to Web services to authorized users. In this paper we present an innovative access control model for Web services. The model is characterized by a number of key features, including identity attributes and service negotiation capabilities. We formally define the protocol for carrying on negotiations, by specifying the types of message to be exchanged and their contents, based on which requestor and provider can reach an agreement about security requirements and services. We also discuss the architecture of the prototype we are currently implementing. As part of the architecture we propose a mechanism for mapping our policies onto the WS-Policy standard which provides a standardized grammar for expressing Web services policies. Keywords:
1.
security, access control, distributed systems, web services, negotiation
Introduction
Nowadays the Web abounds with examples of Web-based enterprise services, and there is an increasing trend amongst them to migrate to the Web services platform in order to enhance and diversify the online services provided to their customers. While shifting from the traditional client-server architecture to WS technology is seen as an endorsement 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 can only reasonably be realized if the unique security challenges posed by this paradigm are appropriately addressed. Security is indeed critical to the wide-scale adoption and integration of Web Services (WS) in distributed enterprise systems and software. Some approaches for securing Web services have been proposed [1, 6, 16] over the last two years. In particular, the SAML [6] and XACML [16] standards provide a sound basis for the development of the secure infrastructure for Web services. SAML, acronym for 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 Security Services Technical Committee. XACML is a specification that is used in conjunction with SAML, and it provides a means for standardizing access control decision for XML documents. Among the various open issues concerning security, an important issue is the development of suitable access control models, able to restrict access to Web services to authorized users. Even though several access control languages have been developed over the past few years, Web services have some specific requirements that require extensions to current access control languages with additional features. In particular, Web services are quite different with respect to objects typically protected in conventional systems, like files or documents, since they consist of software modules, to be executed, upon service requests, according to a set of associated input parameters. Moreover, because Web Services are often published and located on the Web, potential users may belong to different domains and not be known to the parties providing the services. In such a context, traditional access control models are inadequate. To address the above issues, we propose a novel access control model for Web services, for use within the SOAP [3] standard, characterized by capabilities for negotiating 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 without assuming pre-established trust in the users of the web services, while at the same time being in line with recent developments on identity management [5]. Access conditions in Ws-AC are thus expressed in terms of identity attributes1 (attributes, for short) 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 service but only for some specific values of the service parameters. Furthermore our model supports the concept of access negotiation. Although the notion of negotiation has been extensively used in secure communication protocols to establish trust among entities, this notion is only now being investigated in the context of access control policies. Web service negotiation in Ws-AC deals with the possibility for trusted2 users to dynamically change their access requests in order to obtain authorizations, following the suggestions provided by web servers. The negotiation option makes Ws-AC an adaptive system able to drive the subjects toward the specification of acceptable access requests. Counterproposals are dynamically determined by servers during the negotiation. To better address user requests, counterproposals convey acceptable parameter values extracted from original access requests. User trustworthiness is, in our approach, a precondition for negotiating web service properties, and is achieved by enclosing attribute certificates with access requests. In this paper, besides presenting Ws-AC, we propose a system architecture implementing the model, and show how to express Ws-Ac access control policies in a format compliant 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 detailed overview of recent efforts of the Web Service research community for securing web services. Section 3 formally defines the access control model we have designed. In particular, in Section 3.3 we show how to encode Ws-AC policies using Ws-Policy. In Section 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 underpinning the development of the Web Services standard stack framework. This framework, depicted in Figure 1, is the result of the ongoing efforts of several international standard organizations such as Internet Engineering Task Force (IETF) and the W3C, and other initiatives such as OASIS (Organization for the Advancement of Structured Information 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 requirements posed by WS could not be solved by using the HTTPS protocol. HTTPS provides a point-to-point security, that lasts only for the duration of the connection; moreover HTTPS 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 Services can be articulated according to three levels. At the bottom levels (Messaging & Encoding and Transport layers in Figure 1 above), one must provide basic mechanisms assuring integrity and confidentiality of XML data; this is essential since WS technology heavily relies on XML for interoperation. At the intermediate level (Messaging box in Figure 1), one must provide secure messaging protocols. At the top level (Security, Reliability and Transactions in Figure 1) one must assure confidentiality and integrity of messages conveying service invocations and service execution results, and must provide support for authenticating the parties involved in service request exchanges. Moreover, one must provide support for application-dependent access control policies, specifying which subjects 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 roadmap proposed by IBM and Microsoft in April 2002 [10]. • WS-Security. WS-Security [3] defines enhancements to SOAP messaging to provide message integrity and message confidentiality. To achieve this goal, WS-Security specifies 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, the associated security tokens (for example, X.509 certificates) in a SOAP message. • WS-Trust. WS-Trust [8] defines extensions to WS-Security that enable applications to construct trusted SOAP message exchanges. Trust is established through exchange and 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 tokens may be forwardable, delegatable, or proxiable. Security tokens are issued by a Security Token Service (STS). Security token requests may be secured using WS-Security (when exchanging one security token for another), or are secured with an explicit challenge/response or other negotiation protocol (when the requestor does not have a WS security token yet). The Web Service Security framework can in fact support any type of security token. However, security tokens that are to be used across different domains should be interoperable. The following tokens are currently standardized and explicitly supported: username/password combinations and X.509 certificates; binary security tokens, such as Kerberos tickets; and XML security tokens, such as SAML assertions and XrML tokens. • WS-Policy. WS-Policy [7] provides a framework that allows Web Services to describe and communicate (publish) their policies to Web Service requestors. A policy is a collection of one or more policy assertions. Some assertions specify traditional requirements and capabilities such as authentication scheme and transport protocol selection. Other assertions specify requirements and capabilities that have no wire manifestation, yet are critical to proper service selection and usage (e.g., privacy policy, QoS characteristics). WS-Policy provides a single policy grammar to allow both kinds of assertions to be reasoned about in a consistent manner. • WS-SecurityPolicy. WS-SecurityPolicy [9] is an addendum to WS-Security and specifies the policy assertions for WS-Policy which apply to WS-Security. WSSecurityPolicy currently supports the following security policy assertions: – What kind of SecurityToken is required, from whom, and which claims it should provide. – Integrity protection: it is possible to indicate that specific portions of a message be signed and that specific algorithms and keys be used and/or to indicate a set of required claims (assertions) for a signature that are independent of token type or authority. – Confidentiality protection: WS-Policy allows to specify different confidentiality combinations or confidentiality and integrity combinations, or even choices of algorithms. – Visibility: it is possible to indicate the portions of a message that must be processed either by an intermediary or by an endpoint, that is, what portion of a message either
A FINE GRAINED ACCESS CONTROL SYSTEM FOR WEB SERVICES
147
needs to be passed in the clear (unencrypted), or if there must be an encryption binding 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 WSSecurity and to WS-Trust to provide secure conversation across one or more messages. Specifically, this specification defines mechanisms for establishing and sharing security contexts, and deriving keys from established security contexts (or any shared secret). The security context is defined as a new WS-Security token type that is obtained using a binding of WS-Trust. • WS-Federation. WS-Federation [14] describes how to manage and broker trust relationships in a heterogeneous federated environment including support for federated identities, attributes, and pseudonyms. A federation consists of multiple Web Services domains, each with their own Security Token Service–STS–, and with their own security policy. WS-Federation specifies scenarios using WS-Trust, for example to allow requesters from one domain to obtain security tokens in the other domain and 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 on authorization and privacy policies, and integrated processing of pseudonyms (aliases used at different sites/federations). • WS-Privacy. WS-Privacy, as described in [11], will describe a model for embedding into WS-Policy descriptions a privacy language able to express preferences and organizational privacy practice statements, and for using WS-Security to associate privacy claims with a message. Moreover, this specification will describe how WS-Trust mechanisms can be used to evaluate these privacy claims for both user preferences and organizational practice claims. IBM released the Enterprise Privacy Authorization Language (EPAL) Version 1.1 [Release 1.83] [4] specification, defining an interoperability language for exchanging privacy policy in a structured format between applications or enterprises. EPAL is designed as a formal language to specify fine-grained enterprise privacy policies. It concentrates on the core privacy authorization while abstracting from all deployment details such as data model or user-authentication. The Platform for Privacy Preferences (P3P) specification released by the World Wide Web Consortium in April 2002 supports the communication of privacy policies from business applications to consumer applications. EPAL goes one step further, providing an XML language that enables organizations to enforce P3P policies behind the Web, among applications and databases. • WS-Authorization. WS-Authorization [12] will describe how to manage authorization data and authorization policies. This specification will describe how access policies for a Web service are specified and managed. In particular, it will describe how claims may be specified within security tokens and how these claims will be interpreted at the endpoint. This specification will focus on flexibility and extensibility with respect to both authorization format and authorization language. • WS-ReliableMessaging. WS-ReliableMessaging [13] defines a messaging protocol to identify, track, and manage the reliable delivery of messages between exactly two parties, 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-ReliableMessaging provides application source and destinations a guarantee that a message that is sent will be delivered (delivery assurance). It is important to notice that current standardization efforts presented above, like the ones in the areas of XML, SOAP, and WS-Security, were designed to interoperate, in order to address most of the security requirements posed by Web Services. As far as standard access control policies are concerned, the eXtensible Access Control Markup Language (XACML) [16] is an XML specification for defining access control policies for information access over the Internet, developed by the Organization for the Advancement of Structured Information Standards (OASIS). It became a standard in 2003. XACML is designed to support the definition of security policies that can be shared across different applications in a distributed environment. XACML provides a standard for expressing authorization and entitlement policies, which can be shared by heterogeneous security systems. The XACML policy language is based on XML. In addition to policy language, XACML specifies a request and response protocol for describing 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 Policy Enforcement Point (PEP). When the subject makes a resource request, the PEP reformalize 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 determine the authorization decision according to the XACML rules for evaluating policies. The authorization decision response will be expressed using the XACML response language and 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. On the other side, a comprehensive standard solution dealing with access control policies for WS services (WS-Authorization) and fully composable with the Web Service Security standard stack is still under development. Indeed, although several efforts have been done to support security for web services, there is still lack of adaptive use control models that can capture the dynamically changing security requirements of the target enterprises. A further problem related with Web Services security is represented by the lack of mechanisms for preserving privacy of the users. Ws-Privacy is just mentioned in 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 care regards the lack of protocols supporting service compositions. Indeed, to meet the requirements of real-world applications one often needs to combine several different services at application level. Also, a service may need to invoke other services as part of its implementation. Approaches to the problem of secure service composition vary depending on application requirements and on the security policies associated with the various services and thus flexible solutions are required. In the next section we address the issue of access control for web services. We propose an attribute based access control system, referred to as Ws-AC, having negotiation capabilities for web service parameters. Our model is a first concrete effort toward a solution for regulating in a flexible and adaptive way access of web services. In order
A FINE GRAINED ACCESS CONTROL SYSTEM FOR WEB SERVICES
149
to be as flexible as possible the system is implementation independent and can thus function with any specific web service technology. In addition, it is compliant with the existing standards for security for web services. Indeed, as discussed in Section 5 access control policies describing the conditions required to grant access to services are represented 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 are part of our solution to web service access control. Then, we formally define access control 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 web server manages a web service, providing a service called PlaySong, for playing songs at 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 to a set of parameters. The set of parameters characterizing the service is referred to as WSParSet. 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 [Pj 1 , . . . , Pj k ] (j ∈ [1, n]; k ≤ n). The domain of a tuple of parameters is defined as the cartesian product of the domain 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 what follows we represent the domain of WSParSet as a relation, according to the notion of relation of the relational data model. Semantically, a parameter of a web service specifies the condition under which the service can be invoked. These can regard the service features or the quality that can be provided for the service. For instance, in the PlaySong web service above mentioned, a QoS parameter is the bitrate, whereas the song and the corresponding performer are proper service parameters to be specified when customizing the service invocation. The parameters of a service are often related with each other: the value of one parameter can reduce the acceptable values of other parameters of the WSParSet. To represent legal combinations of parameters, parameters are expressed by means of clusters. Precisely, a cluster is modeled as a pair composed by a parameter tuple, named cluster name and a relation name, representing the domain of the tuple. We report the formal definition in what follows. Definition 3.1 (Cluster). Let WSParSet be a set of parameters of a Web Service s of the form WSParSet = {(P1 , domainP1 ), . . . , (Pn , domainPn )}, where (Pi , domainPi ) is a parameter 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 ⊆ domain P j1 × · · · × domain P jk . As introduced, a cluster, in general, is used to define the combination of parameter values that can be accepted as input upon the service invocation. Note that a cluster name can also be composed by a single parameter name. For sake of simplicity, we assume that parameter 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 their domain. Some combination of parameter values, indeed, do not correspond to an existing song. 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 the mentioned parameters. Precisely, R1 ={(“Madonna”, “The Immaculate Collection”, “Vogue”), (“Lenny Kravitz”, “Five”, “Fly Away”)}. The QoS Bitrate parameter, instead, 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, we model 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 associated value; • 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 possible to grant the request, or if a negotiation has to be activated. Operatively, as soon as the access 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 resources allocated to them. Then, during the eventual negotiation, the system always refers to such entries (and associated Id) to verify messages exchange validity. Generally speaking, a negotiation in Ws-AC occurs when the parameters specified within an access request are not acceptable by the server. We further elaborate on this aspect in Section 6.2. In order to negotiate services access control, and formulate adequate counterproposals to be sent to the requesting subject Ws-AC makes use of specific rules traced in the policies governing access to services. As such, before being able to introduce our access control policy language we need to specify structure and semantic of the mentioned rules and
A FINE GRAINED ACCESS CONTROL SYSTEM FOR WEB SERVICES
Figure 2.
151
Context table of listening ratings
parameters. First, we need to introduce the notion of context table. A context table is a table collecting information related with the service and its quality of service. The context table can be used for keeping track a variety of data, for instance the access requests received, the number of users connected to the system, the quality of service of the service to be provided. Such table is dynamically updated each time an access request is received or the context changes. Example 2 An example of context table in our scenario is given by the listening ratings of the songs. Such relation keeps tracks of the number of times a song has been required by 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 that moment. Figure 2 shows the context table “listening ratings”. Such table is referred to as CT1 and its signature is CT1 (Performer, Album, Song, Rate).4 Figure 3 shows a table representing the “average bitrate”. The name of the context table is CT2 and it has the following structure CT2 (UserId, AverageBitrate). To dynamically determine the best values to propose during a negotiation, we make use of particular queries on the context tables. In the following we refer to such type of queries as scripts. Example 3 With respect to the context tables of Example 2 consider the following scripts: 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 listening rating greater than 10000. Script2 , instead, returns the average bitrate value of the user identified by id 0x1234. Finally, Script3 is the parameterized version of Script1 . Having introduced the notions of context table and script we can now define a negotiation trigger. A negotiation trigger is a rule that, when active, automatically binds the parameter names of a cluster either with a tuple of values or with a script. Depending upon 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 to be 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 simple, otherwise it is said parametric. Note that, in case of dynamic triggers, the output of a script can also eventually be empty, which implies that a legal tuple of values cannot be found and the negotiation has to be aborted. We formalize the notion of negotiation trigger 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 associated set 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 is omitted, • 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 of Example 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 the album and the name of the song. In particular, such tuples correspond to Madonna’s song having a listening rating greater than 10000. negT4 returns a tuple5 conveying
A FINE GRAINED ACCESS CONTROL SYSTEM FOR WEB SERVICES
153
the average bitrate of user whose identifier is 0x1234. Finally, trigger negT5 is the parametrized 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 component to authenticate the requester by verifying its attributes, a component for specifying the legal parameter values for the referred service, and a component for supporting the negotiation. We have already defined negotiation triggers, to be used for specifying the component related with negotiation. Next, we define attribute conditions [2], specified within an access control policy for verifying service requestor properties. Definition 3.3 (Attribute Condition). Let Attr be an attribute. An attribute condition C 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 policy pol 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, it is 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 Lenny Kravitz’s song can be played with a bitrate ranging from 64 to 256 by subjects with a subscription of type Gold older than 18. Negotiation triggers have to be carefully associated with dynamic access control policies. Each negotiation trigger controls a cluster of the ClusterSet and it is possible to associate with each cluster at most three negotiation triggers, each of a different type (static, dynamic parametric and dynamic simple). Ws-AC assigns by default a different priority to the trigger execution. Higher priority is always given to the dynamic parametric 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 similar as possible to those specified in the original request. If the execution of such trigger fails, 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 cause security breaches, making access requests not decidable. Based on the above considerations, we need to restrict the admitted policies in those being well formed. The conditions for well formed policies are given in the following definition. Definition 3.5 (Well formed policy). Let pol be an access control policy defined according to Definition 3.4. pol is a well formed access control policy if the following conditions 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 be disjoint, that is, the same parameter names cannot appear in two different clusters. The second condition states that each negotiation trigger controls a cluster appearing in the ClusterSet of the policy. Finally, the third condition requires each cluster of the ClusterSet 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 access control 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}
A FINE GRAINED ACCESS CONTROL SYSTEM FOR WEB SERVICES
Figure 4.
155
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 a subscription 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 well formed. By contrast, policy pol2 is an example of not well formed policy since the clusters 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 specification that defines a general framework to describe a broad range of Web service policies. WsPolicy defines a policy as a collection of alternatives. Each alternative is a collection of assertions. Generally speaking, a policy assertion represents an individual requirement, a capability etc. For instance a policy assertion can specify a particular authentication scheme, a transport protocol selection, a privacy policy, QoS characteristic etc. The normal form schema of a policy according to Ws-Policy is shown in Figure 4. In this schema, * indicates 0 or more, [] indicates that the contained items have to be treated as a group. The wsp:Policy element is used as a policy container. The wsp:ExactlyOne element is used to define a collection of policy alternatives. The wsp:All element instead is used to define a collection of policies assertions each of which must be satisfied. A policy alternative can be considered as a particular 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 alternatives presented by the policy. Moreover if a policy alternative is chosen, the requester must be 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 This example, taken from [7], shows two policy alternatives, each composed by a single policy assertion. The policy has to be interpreted in the following way: if the first alternative is selected, only the Kerberos token type is supported; conversely, if the second alternative is selected, only the X.509 token type is supported. The assertions used in a policy expression can be defined in public specifications, like Ws-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 are understandable potentially from any client. The assertions defined by the entity owning the Web service instead can be understood only from those clients to whom the entity has 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 expressing attribute conditions and parameter conditions (cluster and cluster domain) required by Ws-AC policy formalism (see Definition 3.4). The policy components suitable to be represented as policy assertions are: the set of clusters (ClusterSet component) and the attribute conditions (C component) of a WsAC policy. The NegTSet component is excluded since it conveys information needed by the system and thus there is no need to publish it to clients. Finally, the service name component is excluded because it will be used as unique identifier, as described later in this 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 format compliant to Ws-Policy is reported in figure 7.
A FINE GRAINED ACCESS CONTROL SYSTEM FOR WEB SERVICES
Figure 7.
157
Ws-AC policy represented in a Ws-Policy compliant format
Algorithm 1 formalizes the necessary steps to represent one or more Ws-AC policies in a format Ws-Policy compliant. Basically, the task of the algorithm is to merge all the Ws-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 a policy alternative. The client can choose one alternative among the alternatives provided by the policy. Note that since all the Ws-AC policies referring the same service are merged into a single policy conforming to Ws-Policy, such policy can be uniquely identified by the service name (see for instance Example 7). Function AttributeName(ci ) extracts the name of the identity attributes appearing in condition 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 access to the service “TuningService”. These three policies, according to Algorithm 1, are translated in two Ws-Policy compliant policies. The result is shown in Figure 8. Note that the represented Ws-Policy compliant policy can alternatively be expressed in a more compact form. However, for the sake of simplicity we adopt the normal form described in 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, we provide 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 request can be negotiated and in Section 4.2 we detail the protocol underlying a negotiation in Ws-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 respect to the policies specified for the required service. First, the access request has to comply with at least a policy.
A FINE GRAINED ACCESS CONTROL SYSTEM FOR WEB SERVICES
Figure 8.
Ws-AC policy expressed in Ws-Policy
159
160
BERTINO ET AL.
Definition 4.1 (Policy compliance). Let acc= a, s, p be an access request, and let pol be an access control policy of the form pol = s, ClusterSet, negTset, C. acc complies 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 with a policy defined for the same service if the list of attribute conditions specified in the policy are all evaluated true, according to the attributes sent together with the access request. By contrast, an access request is always rejected if the access request does not comply with any of the existing policies for the requested service. Note that the concept 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 may be granted, as specified in the following definitions. Definition 4.2 (Full acceptance). Let acc= a, s, p be an access request and pol be a policy of the form pol = s, ClusterSet, NegTset, C. We say that acc is fully accepted by 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 : pj 1, . . . , Pjk : pjk ) ∈ acc. p: (Pj1 , . . . , Pjk ) ≡ clusterNamei ∧ (pj1 , . . . , pjk ) ∈ Ri . A full acceptance is thus granted if the parameters appearing in the access request are all and only the parameters specified in the policy, and their value is compatible with the 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”, Album: “The Immaculate Collection”, Song: “Vogue”, Bitrate: 128 acc2 = Subscription:Gold, DateOfBirth: 1978; PlaySong; Performer: “Madonna”, Album: “The Immaculate Collection” acc3 = Subscription:Gold, DateOfBirth: 1970; PlaySong; Performer: “Madonna”, Album: “True Blue”, Song: “Jimmy Jimmy”, Bitrate: 128 The above access requests are all compliant with pol1 . However, acc1 is the only one fully accepted. acc2 indeed specifies a wrong number of parameters whereas acc3 has the 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 of the following conditions hold:
A FINE GRAINED ACCESS CONTROL SYSTEM FOR WEB SERVICES
161
• 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, the NegTSet component of the policy with respect to which the access request is compliant is not empty. Each trigger of a NegTset controls a cluster of the policy. A negotiation trigger 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 domain specified in the policies. Note that it is not required for all the clusters listed in the policy to be controlled by any negotiation trigger. We say that the clusters not associated with 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 accepted because of a non negotiable cluster, the access request is rejected. Otherwise, if the access request is compliant and the incorrect parameters are controlled by negotiation triggers, 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”, Album: “Like A Prayer”, song: “Cherish”, Bitrate: 128 Cluster [Performer, Album, Song]:R1 in pol1 presents a corresponding tuple of values in acc1 that is (“Madonna”, “Like A Prayer”, “Cherish”). However, such tuple does not belong to the cluster domain R1 . Such cluster is controlled by trigger negT1 which can be activated to determine the counter proposal. By contrast, the value (128) specified in the 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 the partially acceptable access request and used to execute the script. Next example clarifies such 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”, Album: “Like A Prayer”, song: “Cherish”, Bitrate: 128
162
BERTINO ET AL.
Like in Example 9, the system executes rule negT1 . Note that Script1 is characterized 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 performer Madonna 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 service parameters in case of access requests compliant with policies for which the wrongly specified clusters (or missing clusters) of parameters are negotiable. The partially accepted access request is the input to a Ws-AC component in charge of determining a valid counterproposal for the required service. We call the message conveying the counterproposal negotiated access proposal or NAP, for brevity. A NAP is generated for each policy with which the access request is compliant, and it carries, like an access request, a set of acceptable parameter values. The intent of a NAP exchange is to 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 conveying one selected among the received ones or it submits a new NAP. The system first verifies that the IdSession submitted within the NAP is related to a negotiation being currently executed. The access control system then evaluates whether the received proposal can be accepted 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 a multi-round fashion until an acceptable proposal is received, or all possible proposals have been sent and no valid access request determined. The described steps of the negotiation are summarized in Appendix A, while the core of the access control algorithm is sketched 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 access request and let pol = s; ClusterSet; NegTSet; C be an access control policy. Let acc be 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 SessionId is a valid Id and refers to the correct session and the access request obtained by replacing the parameter component p of acc with the one specified in the negotiated access proposal 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
A FINE GRAINED ACCESS CONTROL SYSTEM FOR WEB SERVICES
163
access request acc = a; s; p . Let pol be a an access control policy. We say that nap is 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 access request 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 only if the NegTset fields of the corresponding policies are not empty, since it implies that the negotiation can proceed. The function in charge of generating a NAP is Function ProposalGenerator(), which accepts as input an access control policy having negotiation 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 following operations for each cluster conveyed in the policy.
164
BERTINO ET AL.
First, it extracts the corresponding tuple of values specified in the access request by use of function ExtractValues().7 If such tuple is not properly specified the mechanism to 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 policy being wrongly specified). If no negotiation trigger is present for such a cluster, the negotiation is not feasible and the access request is rejected. Otherwise the triggers are executed with respect to their priority. If the trigger execution does not provide correct tuple values for the associated cluster8 the process is interrupted, otherwise one of the tuples generated by the trigger execution is chosen. The selected tuple is passed to function ReturnTuple() which is the function in charge of composing the new NAP. The new 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, and using the above algorithms to determine correct tuples for the others. This process is executed 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}
A FINE GRAINED ACCESS CONTROL SYSTEM FOR WEB SERVICES
165
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 table of Figure 2. Further, consider the following access request: acc1 = Subscription: Gold; PlaySong; Performer: “Alanis Morisette”, Album: “Like a Prayer”, 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 accepted by both. However, since pol2 has no triggers, it cannot activate any negotiation. By contrast, pol1 activates the mechanism for creating a negotiated access proposal. acc1 has a tuple of values corresponding to cluster [Performer, Album, Song] which is not correct. As such, the negotiation triggers controlling the cluster are used. pol1 is composed of triggers negT1 , negT2 negT3 . The first trigger to be executed 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 its execution succeeds since it returns the tuple of values (“Madonna”, “The Immaculate Collection”, “Vogue”). Then, the value specified in the access request for cluster [Bitrate] is checked. Such a parameter is specified with a legal value, as such no trigger execution is required. Finally, the following negotiated access proposal is generated: 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. The negotiation 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 . As such, trigger negT4 is executed and returns value 128. The system builds the following proposal: 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 implementing Ws-AC, shown in Figure 9. We explain the architectural role of the most important modules 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 a negotiated access proposal. If the SOAP message is of the first type, the header of the message conveys one or more attribute certificates and, eventually, an identity certificate. The Message Handler validates the digital credentials by using the XML Validator and the Profile Database storing the public key certificates most widely used. The body of the message conveys the name of the requested service as well as parameter values for the service invocation. The message name is used to check from the Service List Database whether the requested service is actually available.
A FINE GRAINED ACCESS CONTROL SYSTEM FOR WEB SERVICES
Figure 10.
167
Example of access request generated by the Message Handler
After the digital credentials validation and the verification of the service availability the Message Handler composes an access request. Such a request is stored together with a 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 the message conveys the IdSession and the parameter values for the service invocation. The Message Handler checks the existence of such an identifier in the IdsTable and extracts the associated access request. The parameter values of the access request are then replaced with the parameters values extracted from the negotiated access proposal of 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 request can be fully or partially accepted or it has to be rejected. Specifically, to give such a response, the Authorization Manager module runs Algorithm 2. If the access request is rejected, the Authorization Manager sends a message to the Message Handler notifying that the access cannot be granted. The Message Handler builds a proper SOAP message to be sent to the client. If the access request can be fully accepted, 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 the Context Tables. Finally, if the access request is partially accepted it is sent together with all the related policies to the Negotiation Agent. The Negotiation Agent, in turn, creates proposals for each policy by activating the corresponding negotiation triggers by executing Algorithm 3. Such parameters value proposals are sent to the Message Handler which builds the corresponding negotiated access proposal. 5.3.
Control panel
The Control Panel is an administration module enabling the system administrator to create, edit and remove policies, negotiation triggers, scripts and context tables. It is used as a front end to program the Context Tables Manager, in order to execute the desired update on the Context Tables when an access request is received.
168
Figure 11.
BERTINO ET AL.
Ws-AC behavior upon an access request
Finally the Control Panel provides a graphical user interface to automatically map Ws-AC policies in a Ws-Policy compliant format. The policies represented in such a format can be published into UDDI registries for being read by any potential client.
A FINE GRAINED ACCESS CONTROL SYSTEM FOR WEB SERVICES
Figure 12.
6.
169
Ws-AC negotiation
Conclusion
Although several research and standardization efforts have been recently undertaken to address 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 to be addressed. In this paper we have proposed Ws-AC, an innovative, implementationindependent, approach to access control. The model is characterized by a number of key features, including identity attributes and service negotiation capabilities. In the paper we have formally defined the protocol for carrying on negotiations, by specifying the 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 also discussed the architecture of the prototype we are currently implementing. As part of the architecture we have proposed a mechanism for mapping our policies onto the WSPolicy standard which provides a standardized grammar for expressing Web services policies. 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 with existing standards. In particular, the possibility of exploiting XACML still has to be analyzed. Further, since this aspect is still missing in the Ws-Security stack, we would like to integrate our model with mechanisms for supporting privacy of the users, to allow clients to confidently send private credentials to unknown services. A prototype of the Ws-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 of the 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, credit cards. 2. In this context, by trusted users we mean subjects whose associated attributes have been validated by the server. 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 used in the example: wsse http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd http://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/
A FINE GRAINED ACCESS CONTROL SYSTEM FOR WEB SERVICES
171
[6] Advancing SAML, an XML-based security standard for exchanging authnetication and authorization information. 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). Version 1.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 and Roadmap. 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/wsfederation.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, 30 Sep 2004 http://docs.oasis-open.org/xacml/access control-xacml-2.0-core-spec-cd-02.pdf
