C OV E R F E AT U RE
Modeling Trust Negotiation for Web Services Halvard Skogsrud, ThoughtWorks Hamid R. Motahari-Nezhad and Boualem Benatallah, University of New South Wales, Australia Fabio Casati, University of Trento, Italy
As Web services become more widely adopted, developers must cope with the complexity of evolving trust negotiation policies spanning numerous autonomous services. The Trust-Serv framework uses a state-machine-based modeling approach that supports life-cycle policy management and automated enforcement.
W
eb services that offer limited or no access to the general public typically rely on knowing requester identities in advance.1 For a growing number of Web services, however, the majority of users are unknown to the provider.2 Among access control models that address the problem of unknown users, trust negotiation has attracted the most attention in industry and academia.3,4 Rather than relying on requesters’ identities, this approach makes access decisions based on a level of trust established between the requester and provider. During a trust negotiation, the parties exchange cre-
54
computer
dentials, signed assertions that describe some owner attributes—for example, digital versions of driver’s licenses, passports, or membership cards. Negotiation becomes important when the user attributes included in credentials are sensitive in nature, such as credit card information, medical data, or criminal records, because the holder of such information might only want to disclose that information under particular conditions. Trust negotiation policies direct the participants’ behavior—they describe which credentials are required to access some resource, and which can be disclosed during the negotiation. However, such policies are notoriously hard to develop and maintain because no frameworks for managing their evolution currently exist.5 This is particularly true of dynamic Web services environments. The management of policies during their entire life cycle is an often-overlooked part of policy model design. Policies are rarely set in stone when first defined. Instead, they are usually modified and refined to reflect changing security strategies. Evolving business strategies or laws can also cause policy changes. Managing changes in deployed Web services is difficult and costly, especially because service
Published by the IEEE Computer Society
0018-9162/09/$25.00 © 2009 IEEE
interactions can span numerous autonomous services, last a long time, and be governed by agreed-upon contracts. Changes might violate several types of constraints, including internal consistency (for example, restrictions on the relationship between roles) and interaction contracts (for example, revocation of granted access rights). This can have serious consequences such as unauthorized access to sensitive information and penalties for noncompliance with laws or contracts.
Trust Negotiation A guiding framework is a prerequisite for understanding trust negotiation in the context of Web services security.
Example scenario Figure 1 shows an example trust negotiation scenario involving Alice, a research student who wishes to access the digital library of a university she does not attend. Alice is the requester, and the digital library is the service provider. Alice wishes to read a journal article she found by searching the library via its public Web interface. She therefore sends a message containing a request for the journal article to the library. Because Alice is not a known student of the university and has not used this library before, there is no existing trust relationship between Alice and the library. Hence, the library will consult its trust negotiation policy to determine what Alice must do to use the service. In response to Alice’s article request, the library asks for proof of her student status. More specifically, it requests a student credential from Alice. This credential is required by the library’s policy to gain access to journal articles. Alice does indeed have a student credential from her own university. However, because this credential contains information such as her student number, she does not allow the credential to be disclosed to everyone who requests it. Alice has her own trust negotiation policy, which sets out the conditions under which she will disclose her student credential and other credentials. Because Alice frequently accesses articles from online libraries, software installed on her computer performs the negotiation automatically according to the policy she has specified. However, she can also perform the negotiation manually. To disclose the student credential, Alice’s policy requires a credential from the other party certifying that it belongs to an accredited university. Hence, in response to the library’s request for Alice’s student credential, Alice sends a request for the library’s proof of university affiliation. In this case, the library possesses such a credential, issued by the university it belongs to, and ac-
Alice
Library 1. Request journal article 2. Request student credential 3. Request affiliation credential 4. Disclose affiliation credential 5. Disclose student credential 6. Receive journal article
Figure 1. Simple trust negotiation between Alice, a research student who wants to access the digital library of a university she does not attend, and the library.
cording to its policy is willing to disclose this credential at any time. The library proceeds to send this credential to Alice. Now that the condition Alice set to disclose her student credential has been fulfilled, she sends the credential to the library. Because its policy for giving access to journal articles has now been satisfied, the library sends the article to Alice.
Scenario analysis In this scenario, both Alice and the library must define their trust negotiation policies. However, because these policies are likely to evolve over time (for example, Alice might start working at another library and obtain an employee credential that she wishes to include in her policy), the policies should be specified in a manner that makes evolution feasible. Hence, a way to model a trust negotiation policy is desirable, along with a management framework for making changes to the model. During the negotiation, neither participant wishes to disclose more credentials than necessary. This is particularly true for Alice, who has legitimate privacy concerns as a private citizen. Hence, the participants might wish to negotiate in a manner that avoids unnecessary credential disclosure. Other participants might have other requirements. For instance, the library might be less concerned about unnecessarily disclosing credentials than about reducing server load by having each negotiation consume as few server resources, such as CPU time and memory, as possible. Support for these different negotiation techniques is thus important. Trust negotiation participants usually want some control over how the other party uses the disclosed credentials once the negotiation ends—for instance, how long the FEBRUARY 2009
55
cover F E AT U RE information is kept, what it will be used for, and who has access to it. Hence, during the negotiation, participants might want to set privacy policies regarding the information revealed as well as credential disclosure.
Research Frameworks The example scenario underscores three key dimensions of a framework for understanding trust negotiation: policy modeling and management, resource protection, and privacy.
Trust-Serv models are independent of the formal language used to enforce the policy.
Trust-Serv Trust-Serv7,9,10 is a framework for modeling trust negotiation policies for Web services that, unlike existing approaches, supports both life-cycle management and automated enforcement. It extends the familiar state machine framework with abstractions that provide the expressiveness required to model a trust negotiation policy, including representations for the level of trust established, credential disclosures, and provisions. Trust-Serv models are independent of the formal language used to enforce the policy.
Policy modeling and management
State machines
Because developing trust negotiation policies is generally considered to be difficult,5 providing good modeling tools is important for successful trust negotiations. Researchers have developed several useful methods to model trust negotiation policies. For example, administrators can use IBM’s Trust Establishment framework1 to define policies in a visual editor and then transform them into an XML policy document. Kent Seamons, Marianne Winslet, and Ting Yu6 developed a graph-based system to model policies. Using their TrustBuilder tool, administrators can define policies for each credential or service independent of the actual policy language used.
A trust negotiation policy specifies which privileges are granted at various states of the negotiation, as well as the conditions for disclosing them. State machines have several advantages in this regard:
Resource protection
Algorithms can transform the graphical models into specifications that an engine can use to automatically enforce the policy.
Most recent work on trust negotiation has focused on how to reveal credentials.3,5 Many different strategies are possible from most to least restrictive.4 A restrictive approach often leads to a longer negotiation with more messages being exchanged, while a relaxed policy can lead to the disclosure of unnecessary credentials. However, the choice of negotiation strategy does not depend on the choice of policy language or the actual policy.
Privacy Privacy is related to resource protection, but the two dimensions have a fundamental difference: Resource protection is about preventing information from being unnecessarily disclosed, while privacy is about protecting information after it has been released. Many studies recognize the importance of privacy,3,4,7 especially in business-to-customer interactions where the customer must disclose credentials containing personal information to the service provider, but it has received less attention than resource protection.
56
Proposed privacy standards for Web applications such as the Platform for Privacy Preferences have been extended to include Web service support (www.w3.org/ P3P/2003/p3p-beyond-http). The Trust-X framework supports privacy preservation by integrating P3P into the trust negotiation.3,8
computer
•
• •
the graphical nature of state machines closely resembles the gradual establishment of trust as the negotiation progresses; the visual nature of state machines makes policy creation and evolution easier; and state machines possess a formal semantics that can be used to control trust negotiations.
Modeling and enforcing policies In Trust-Serv, resources are credentials and service end points identified by, for instance, uniform resource identifiers (www.w3.org/Addressing). Credentials must be protected because they can contain sensitive information. Requesters interact with the service by sending messages to the service end points defined in the service interface contract. Figure 2 shows a trust negotiation policy for a Web service interface to a digital library, such as that used in the example scenario. Role-based access control. A state represents the level of trust the requester achieves in the negotiation. By entering a new state, the requester obtains access to more resources. Instead of assigning resources directly to states, Trust-Serv uses role-based access control. Roles
Begin
C: credential
P: provision
T: timeout
Guest
T [30 min] End
C [library ID]
P [invoke ‘Register’]
Registered user
C [university ID]
Affiliate university user
C [employee e&& e.position=librarian] Editor
Figure 2. Example trust negotiation policy for a Web service interface to a digital library in Trust-Serv.
are semantic abstractions that describe some function performed by a person or process—for example, author or editor. Trust-Serv assigns permissions to such roles rather than individual users, and users can play one or more roles.11 State labels indicate what roles are mapped to a state. The requester can play the roles of a state once it reaches that state. Requesters build trust by submitting credentials as specified by the provider’s trust negotiation policy.
Provisions. Trust-Serv represents provisions as service operations that must be invoked before a negotiation can proceed. For instance, the dotted line in Figure 2 indicates a provision that requires the requester to invoke the Register operation. This transition is included as an alternative to submitting a library ID credential. The intention in this example is that requesters can instead register at the service and provide their identity through the Register operation.
Transitions. Trust-Serv extends transitions beyond traditional state machines to capture security abstractions necessary for trust negotiation by labeling them with authorization abstractions. These define the conditions the negotiation must meet to fire transitions. The semantics are as follows: When the negotiation is in a state S and an event occurs that satisfies the condition of a transition T where S is the input state, then the negotiation moves to T’s output state. Requesters explicitly trigger events by invoking operations such as credential disclosure. A requester chooses transitions based on two criteria. The requester first narrows the choice according to which resource it desires. Transitions are considered only if they are part of a path that leads to a state containing a role that gives the requester the access right it desires. Second, the condition on the transition must be compatible with the requester’s own trust negotiation policy. If a transition requires a credential to be disclosed, for instance, the requester’s policy must allow this disclosure.
Timeouts. If the requester takes no action within a given time, Trust-Serv aborts negotiations by forcing a transition to a final state with a timeout. For instance, the dashed line in Figure 2 is a timed transition that requires the requester to take action within 30 minutes.
Trust negotiation controllers Negotiation controllers interpret and enforce trust negotiation policies in Trust-Serv as shown in Figure 3. When a requester sends a message to a service, the service’s negotiation controller acts like a proxy and intercepts the message. The controller can then forward the message to the service for processing and either reject it or initiate a negotiation with the requester to establish sufficient trust to allow the service to process the message.
Implementation We implemented a functional prototype of the TrustServ framework.12 The prototype’s main components are a FEBRUARY 2009
57
cover F E AT U RE
Requester’s policy
Requester
Web service
Requester’s negotiation controller
Provider’s negotiation controller
Provider’s policy
Figure 3. Interaction between service providers and requesters in Trust-Serv. Negotiation controllers interpret and enforce trust negotiation policies.
Web Services and Trust Negotiation Trust negotiation can protect both HTTP and SOAPbased Web services. These services can be either browser- or desktop-based applications directly accessed by human users or services that take part in some business process but are only invoked by other services. In protecting these different types of services, the modeling approach is the same but implementations differ. Table 1 summarizes the key features of currently available standards and their application in trust negotiation.
Services directly accessed by users Most HTTP-based Web services are browser-based applications. In recent years, innovative ways to authenticate users for such services have emerged.
Figure 4. Trust-Serv prototype trust negotiation modeler. This screenshot shows two policies being edited, one in the top part of the window and one in the bottom part.
• •
•
modeler to create and evolve policies and translate them to control tables, controller that reads the generated control tables and enforces them in a manner transparent to the protected Web service, and policy evolution manager to perform change impact analysis.
To support life-cycle management, the modeler lets developers specify and modify negotiation policies, as well as define strategy selection policies. Figure 4 shows the modeler interface’s editor for describing a policy’s state machine diagram.
58
computer
CardSpace. Microsoft’s Windows CardSpace (www. microsoft.com/net/windowscardspace.aspx) includes an identity selector that a Web service can trigger on the computer of a client that has requested a resource. The selector lets users choose one of their credentials, called InfoCards, that satisfies the service provider’s policy. CardSpace does not currently support automated clientside trust negotiation—a user must choose whether to disclose a credential in response to a request from the service provider as well as which credential to disclose if more than one is acceptable. SAML. The Security Assertion Markup Language (www. oasis-open.org/committees/security) standardizes several types of credentials, known as assertions, for use between services. SAML attribute assertions support claims of various attributes of the negotiation participants. In addition, profiles supporting browser-based clients and HTTP bindings enable trust negotiation for human users. However, SAML lacks rich user interface requirements that allow the building of uniform client software like the InfoCard selector to help users choose credentials to dis-
close and understand detailed credential requests from service providers.
Services not directly accessed by users The same underlying protocols in CardSpace and SAML that secure interactions between two services directly accessed by users can also support trust negotiation between two services not directly invoked by users. Also, because Web browsers are not the only clients, additional bindings including SOAP and profiles—for example, SAML’s SOAP binding—are available to support richer interactions. However, with no way for humans to decide which credentials to disclose and when, there must be software on the client side to automatically select appropriate credentials according to a client’s trust negotiation policy.12
Other Web service specifications Various Web service security standards also support trust negotiation. WS-Security provides message-level security for SOAP messages; using this specification, developers can encrypt, sign, and authenticate SOAP messages, and attach binary files such as X.509 certificates. WS-SecureConversation establishes a secure context for more efficient trust negotiation. WS-SecurityPolicy specifies what credential types a negotiation participant supports. WS-Trust describes a security token service that can mediate negotiations between interacting services by translating credentials to the required formats and validating them. The Trust-Serv implementation makes use of WSSecurity for transmitting certificates and WS-Trust for validating them.
policy Change Management Trust negotiation policies evolve over time to reflect changing security and business strategies.13 Issues that
must be considered in life-cycle management frameworks include how to update such policies consistently and how to cope with dynamic policy evolution—that is, changing a policy during active negotiations. This might be required for long-running interactions such as immigrant visa applications. Trust-Serv offers solutions for both policy change management and ongoing trust negotiations affected by policy changes.
Changing trust negotiation policies Trust-Serv provides a set of basic change operators, called primitives,7 to change trust negotiation policies in various ways: AddTransition and RemoveTransition, MapRole and UnmapRole, and AppendState and RemoveState. Because each primitive takes a policy as input and returns a policy as output, they can be chained together in a sequence. In this way, developers can develop higher-level operations for common changes.
In-flight trust negotiations Once an initial policy PI evolves into a final policy PF, developers must decide how to handle ongoing negotiations that began under PI. Trust-Serv offers four strategies to migrate the negotiation instances once their respective classes are identified during the impact analysis: concurrent to completion, abort, migration to new policy, and migration to hybrid policy.10 Concurrent to completion. The negotiations in progress complete according to PI, and new negotiations start according to PF. This means the enforcement system might need to enforce more than one policy at a time. Abort. The negotiations abort, and all roles attained by the requesters deactivate. This strategy is very useful when trust negotiations are short-lived and when restart-
Table 1. Trust negotiation features in Web service and Web-related security specifications. Specification
Feature
Use
Windows CardSpace
InfoCard identity selector
Human users select credential to be disclosed to service provider Protocols for exchanging credentials and credential requests
Security Assertion Markup Language (SAML)
Assertions (in particular, attribute assertions) Profiles define assertion requests and exchange protocols
Flexible credential implementation; XML format suits Web-services-based solution
WS-Security and WS-SecureConversation
SOAP message encryption and signatures
Maintain confidentiality of credential information during transmission, including across untrusted intermediaries
WS-SecurityPolicy
Message security policy requirements specification
Define acceptable credential types such as SAML and X.509
WS-Trust
Security token service
Validate credentials disclosed Mediate between parties requiring different credential types—for example, requester has X.509 certificate and provider wants SAML assertion
FEBRUARY 2009
59
cover F E AT U RE ing will lose little work. The main drawback is that it can waste a lot of effort expended in cases with long-lasting trust negotiations. Migration to new policy. The negotiation migrates to PF. The migration is unconditional if the negotiation instance N complies with PF—that is, if PF contains all states visited by N, all active roles of N (which must be mapped to states visited by N), and all transitions fired by N. However, if the instance does not comply with PF, the migration is conditional. Conditional migrations require the negotiation instance to trace back steps in the policy until it reaches a state where it complies with PF. Migration to hybrid policy. Instead of rolling back noncompliant negotiations, this strategy defines them by a temporary policy. Its function is to modify existing negotiation instances to comply with the requirements causing the policy change from PI to PF. Such a strategy is useful if the policy modification is critically important but aborting is too disruptive.
Analyzing the impact of policy changes To help policy developers and managers make appropriate migration strategies for ongoing trust negotiations, Trust-Serv supports replaceability analysis to determine the circumstances under which a new policy can replace an old one.10 Negotiations can be classified using one of three operators: total—replace policy P1 with a new policy P2; postfix—identify the states from which the changes in the new policy are transparent to the clients so that they can continue with the old policy; and prefix—identify running instances in states not yet affected by the change.
T
he focus of Web service trust management today is on the basic infrastructure—protocols and languages. As technology matures and Web services become more widely adopted, developers must cope with the complexity inherent in managing large volumes of services. This complexity increases when such services are part of collaborative business processes involving multiple partners with different priorities. There is a need for flexible approaches to authorization, such as trust negotiation, when dealing with applications that serve numerous user types. Modeling can also be a visual aid to users and developers and aid in life-cycle policy management. Work in this direction is under way, with frameworks like Trust-Serv that support security modeling.1,14 However, a more comprehensive methodology is required not only to help developers identify assets to protect but also to analyze possible attacks and assess protection levels, alternative solutions, and tradeoffs.
60
computer
References 1. A. Herzberg et al., “Access Control Meets Public Key Infrastructure, Or: Assigning Roles to Strangers,” Proc. 2000 IEEE Symp. Security and Privacy (SP 00), IEEE CS Press, 2000, pp. 2-14. 2. T. Grandison and M. Sloman, “A Survey of Trust in Internet Applications,” IEEE Comm. Surveys & Tutorials, Oct. 2000, pp. 2-16. 3. E. Bertino, E. Ferrari, and A.C. Squicciarini, “Trust-X: A Peer-to-Peer Framework for Trust Establishment,” IEEE Trans. Knowledge and Data Sharing, July 2004, pp. 827-842. 4. T. Yu, M. Winslett, and K.E. Seamons, “Supporting Structured Credentials and Sensitive Policies through Interoperable Strategies for Automated Trust Negotiation,” ACM Trans. Information and System Security, Feb. 2003, pp. 1-42. 5. M. Winslett et al., “Negotiating Trust on the Web,” IEEE Internet Computing, Nov./Dec. 2002, pp. 30-37. 6. K.E. Seamons, M. Winslett, and T. Yu, “Limiting the Disclosure of Access Control Policies during Automated Trust Negotiation,” Proc. 2001 Network and Distributed System Security Symp. (NDSS 01), Internet Society, 2001; www. isoc.org/isoc/conferences/ndss/01/papers/seamons.pdf. 7. H. Skogsrud, B. Benatallah, and F. Casati, “Trust-Serv: Model-Driven Lifecycle Management of Trust Negotiation Policies for Web Services,” Proc. 13th Int’l Conf. World Wide Web (WWW 04), ACM Press, 2004, pp. 53-62. 8. E. Bertino, E. Ferrari, and A.C. Squicciarini, “PrivacyPreserving Trust Negotiations,” Privacy Enhancing Technologies, LNCS 3424, Springer, 2004, pp. 283-301. 9. H. Skogsrud, B. Benatallah, and F. Casati, “Model-Driven Trust Negotiation for Web Services,” IEEE Internet Computing, Nov./Dec. 2003, pp. 42-52. 10. H. Skogsrud et al., “Managing Impacts of Security Protocol Changes in Service-Oriented Applications,” Proc. 29th Int’l Conf. Software Engineering (ICSE 07), IEEE CS Press, 2007, pp. 468-477. 11. D.F. Ferraiolo et al., “Proposed NIST Standard for RoleBased Access Control,” ACM Trans. Information and System Security, Aug. 2001, pp. 224-274. 12. H. Skogsrud et al., “Trust-Serv: A Lightweight Trust Negotiation Service,” Proc. 30th Int’l Conf. Very Large Databases (VLDB 04), VLDB Endowment, 2004, pp. 1329-1332. 13. J. Rees et al., “PFIRES: A Policy Framework for Information Security,” Comm. ACM, July 2003, pp. 101-106. 14. D. Basin, J. Doser, and T. Lodderstedt, “Model Driven Security: From UML Models to Access Control Infrastructures,” ACM Trans. Software Eng. and Methodology, Jan. 2006, pp. 39-91.
Halvard Skogsrud is a senior consultant with ThoughtWorks, which delivers large-scale distributed software systems for a diverse range of clients. He is also a Visiting Fellow at the University of New South Wales (UNSW), Australia. His research interests include secure and scalable distributed systems, including Web and Web-based services. Skogsrud received a PhD in computer science and engineering from UNSW. Contact him at halvard@ skogsrud.com.
Hamid R. Motahari-Nezhad is a postdoctoral fellow in the School of Computer Science and Engineering at UNSW. His research interests include Web services interactions analysis and management and service engineering. Motahari-Nezhad received a PhD in computer science and engineering from UNSW. He is a member of the IEEE and the Australian Computer Society. Contact him at hamidm@ cse.unsw.edu.au. Boualem Benatallah is a professor in the School of Computer Science and Engineering at UNSW, where he is also founder and leader of the Service-Oriented Computing Research Group. His research interests include Web service protocols analysis and management, enterprise services integration, process modeling, and service-ori-
ented architectures for pervasive computing. Benatallah received a PhD in computer science from the University of Grenoble, France. He is a member of the IEEE. Contact him at
[email protected]. Fabio Casati is a professor of computer science in the Department of Information and Communication Technologies at the University of Trento, Italy. His research focuses on middleware for integration and analysis of middleware data, bringing and extending traditional integration technologies to all enterprise data and to the Web, and improving how scientists produce, disseminate, evaluate, and consume scientific knowledge. Casati received a PhD in computer science and engineering from Politecnico di Milano, Italy. Contact him at
[email protected].
Call
for
Articles
IEEE Software seeks practical, readable articles that will appeal to experts and nonexperts alike. The magazine aims to deliver reliable information to software developers and managers to help them stay on top of rapid technology change. Submissions must be original and no more than 5,400 words, including 200 words for each table and figure.
Author guidelines: www.computer.org/software/author.htm Further details:
[email protected]
www.computer.org/software FeBruArY 2009
61
