=Paper=
{{Paper
|id=Vol-1099/paper6
|storemode=property
|title=Trust Negotiation for Automated Service Integration
|pdfUrl=https://ceur-ws.org/Vol-1099/paper6.pdf
|volume=Vol-1099
|dblpUrl=https://dblp.org/rec/conf/aiia/TomaiuoloA13
}}
==Trust Negotiation for Automated Service Integration==
https://ceur-ws.org/Vol-1099/paper6.pdf
Trust Negotiation for Automated Service Integration
Filippo Agazzi, Michele Tomaiuolo
Dipartimento di Ingegneria dell'Informazione
Università di Parma
Parma, Italy
{agazzi, tomamic}@ce.unipr.it
Abstract—This paper presents a generic Trust Negotiation This paper is organized as follows: Section II presents an
framework for Web services, based on the WS-Trust standard. It overview and a literature review of ATN; Section III describes
allows users to create trust incrementally, by disclosing a generic trust negotiation framework for Web services, based
credentials step by step. This way, services and resources can be on the WS-Trust standard; Section IV provides details about
shared in an open environment, and access can be realized on the practical implementation and use of such a framework,
basis of peer-to-peer trust relationships. The paper also describes including first performance results; finally, some concluding
a practical implementation of the framework, which integrates a remarks are provided.
modular trust engine and a rule engine, which is used as a policy
checker.
II. BACKGROUND
Security; trust; Web services; rule-based systems A credential is generally defined as a digital certificate
attesting, via a digital signature, the association of one or more
I. INTRODUCTION attributes to an entity, identified through its public key. This
entity, i.e. the certificate subject, can attest the ownership of the
The automatic or assisted management of trust relationships presented credential by demonstrating to possess the
is a fundamental requirement to allow the provision and use of corresponding private key. Notably, the entity that originally
disparate services in an open environment. At the global scale, issued and signed the certificate is not necessarily requested to
the assumption that all users are known in advance, or they can participate directly in the verification process.
be easily managed through a traditional Access Control List, is
not realistic. In fact, the potential user base of an application Attributes in a credential can be considered sensible or not.
provided on the open Internet is still growing, with the mass The case of non-sensible attributes does not require any
adoption of social networking tools. Since nowadays contacts particular care. On the contrary, for the case of sensible
among people may develop fully online, possibly with no body attributes, it is necessary to build a certain level of trust
of knowledge to associate with a name, more flexible schemes between negotiating parties via a structured list of release
are needed. Currently, no general solutions are available for the conditions. Such release conditions are generally known as
problem of identity management, assuming a global database policies. An access policy for a resource R is a boolean
of names and personal profiles is both unfeasible and function, which allows or denies access depending on disclosed
undesirable. Moreover, online interactions may involve human credentials. It can be written as: fR(C1, C2, … Cn), where each
users together with software agents, possibly with a common Ci is a credential which may be possessed by the requester. A
understanding of the exchanged messages, on the basis of credential itself often holds sensitive information, and it needs
Semantic Web technologies [1]. Given such a new way people to be protected. Thus a credential disclosure policy should be
are using the Internet today, the approach of Automated Trust defined for revealing a certain credential C. It will be a boolean
Negotiation (ATN) [2][3] is becoming relevant, because it function of the form: fC(C1, C2, … Cn). Finally, for selecting the
allows unknown users and agents desiring to share any credentials to disclose, a client could need to access a service
resource or service, to establish a level of trust in an policy P. But also this policy can be considered reserved. In
incremental way through the exchange of credentials. this case, it should be associated with a policy disclosure
policy: fP(C1, C2, … Cn). That is, credentials and policies are to
In this scenario, the open selection and composition of be considered as sensitive resources, and thus they need to be
services is made possible, since ATN simplifies the creation protected by access policies, along other kinds of resources.
and management of trust bounds. In fact, delegation and Access control can be implemented on the basis of different
workflow composition [4] may only be applied on the basis of kinds of security credentials, including X.509 certificates and
careful protection of resources and information. This requires a SAML assertions. Moreover, different languages have been
clear analysis of risks and opportunities associated with local defined to represent policies [7][8] in an appropriate and
trust bounds, on the basis of their socio-cognitive constituents expressive way.
[5], including competence, disposition, dependence and
fulfillment. The problem of authorization can thus be solved in These are the cases where trust negotiation provides its full
a fully distributed way, as access rights can be assigned and benefits. Digital credentials are exchanged step by step, to
delegated on the basis of the local trust assumptions, in a increase the level of trust between involved parties, and the
typical Trust Management scheme [6]. flow of credentials between two entities through a sequence of
requests and releases is what is actually intended with trust which credentials are released, when they are released, which
negotiation. parties are required to unlock the release of another credential
and when the negotiation closes, successfully or not. The
A policy language for Trust Negotiation must allow to success of a negotiation is not always possible. One of the
specify all these conditions. A policy has to be considered subjects could not have all the needed credentials, or one of the
satisfied only when the requester discloses all the required subjects could implement a policy imposing a cyclic
credentials, and this verification requires to use a formal policy dependency. Therefore, it is worth defining properties that
language, with precise semantics. Another important should be expressed, in the best possible way, by a strategy:
consideration is that, to fit the wide Internet, such language has
to be comprehensible and agreed by all involved entities. In the • A strategy should bring a negotiation to success, when
last years, scholars and firms have proposed various languages, such a possibility exists. Strategy having such a
like the IBM Trust Policy Language or the Role-Based Trust property are said to be complete.
Management Language (RT). All those languages, however, • Ideally, a strategy should avoid the release of
were related to some particular engines to compute and decide information which is not strictly required to bring the
about certain policies. Moreover, a number of languages are negotiation to an end.
being proposed by ongoing research works, but with a limited • A strategy should truncate a negotiation when it
scope of application, to be shared by some nodes which cannot bring to a successful conclusion.
interact using the same framework or the same software
• A strategy should recognize a cyclic dependency
infrastructure, for example in the context of Web Services.
among credentials and policies.
With respect to the management and computation of • The strategy should be reasonably efficient.
policies in a trust negotiation, a particularly important element
is the policy compliance checker. Starting from a policy and a There is a vast choice of possible negotiation strategies,
set of credentials, the policy compliance checker must be able each one with its peculiar features. An important distinction
to find the credentials which satisfy the policy, if they are can be drawn upon the level of prudence in the disclosure of
effectively available as a subset of all disclosed credentials. For credentials and policies. In [2] and [7], the following strategies
this purpose, it is also necessary to translate each credential are considered:
from its original format into an assertion of the policy Eager Strategy. This strategy is complete and efficient.
language. Considering the example of a client requesting a Participants release all their credentials as soon as the relevant
service, one of the problems to solve is how the client comes to policy is satisfied, without waiting the credential to be
know which credentials it is required to present, and how the requested. This strategy is very simple and brings the
policies protecting the service and the credentials are disclosed. negotiation to success whenever it is possible. Nevertheless, it
reveals more credentials than those strictly needed to create the
A. Negotiation Strategies minimum level of trust.
From the architectural point of view, each entity Parsimonious Strategy. In this strategy, the number of
participating in an Automated Trust Negotiation has a Security exchanged credentials is minimized. It is reasonably efficient
Agent (SA). The SA has the fundamental responsibility of and it concludes with success whenever it is possible. At the
managing the negotiation, computing available policies and beginning, parties exchange credential requests, but not the
credentials, both the local ones and those disclosed by a remote credentials themselves. All possible release sequences are then
entity, and taking the decision to authorize the disclosure of explored. The path that brings the negotiation to success with
some credentials and policies at a given phase of a negotiation. the minimum number of exposed credentials is selected and
These decisions, as well as the exchanged messages and the followed. Unfortunately, due to the possible limitations in the
disclosure of policies and credentials, can be conducted in a level of cooperation between two subjects, the global minimum
number of ways, which is essentially unlimited. A negotiation solution is not guaranteed.
strategy defines the protocol for the modality and decisions.
Prudent Strategy. This strategy allows establishing trust
The main goal of a strategy is to reach a successful without revealing irrelevant credentials, while remaining
completion of the negotiation protocol, in the respect of certain reasonably efficient. In [9] the communication complexity is
requirements. A strategy decides when and which credentials shown to be O(n2), and the computational complexity to be
must be disclosed and inserted into a message to send to the O(nm), where n is the number of credentials and m is the size of
other party; how much computational load to dedicate to the the policy regulating the release of credentials.
negotiation (e.g., the maximum number of rounds) and other
decisions about the behaviour to pursue during the negotiation. In the heterogeneous world of Internet, each entity must be
Moreover, a negotiation is not always possible, since for free to choose the strategy that is the best compatible with its
example one of the two parties does not possess sufficient own requisites and objectives. It is quite possible that two
credentials: the strategy has to determine the moment to unknown entities will choose different strategies. Thus, there is
abandon the negotiation, since it is not possible to conclude it a problem of how to make such strategies interoperable, and if
with success. it is possible. In [10], a family of strategies, called DST
(Disclosure Tree Strategy), is proposed as a solution to this
The execution of a negotiation requires some agreement on problem. A family of strategies is defined as a set of
a common protocol, with the intended agreement that each reciprocally compatible and interoperable strategies. An
subject is free to apply a possibly different strategy. The important advantage regards the fact that a Security Agent can
characteristics of a negotiation are defined by the adopted choose, among a set of strategies belonging to the same family,
strategies. Some of the tasks of such strategies are related to the closest one to its own requisites. Moreover, this way it can
adopt different strategies, during the different stages of a can request that a received message proves a set of claims (e.g.
negotiation. name, key, privileges, etc) or, more commonly, that it carries a
security token representing a relation between the sender and
III. APPLICATION OF ATN TO WSS some other entity, trusted by the service provider. In this
context, a service provider can request a client, before
This section describes a generic trust negotiation protocol accessing its services, to present a token released by a trusted
for web services. The protocol is designed in conformance to entity. A new client would probably not possess a proper token
relevant standards for Web services security. Thus, it first to access the service, in advance. For this reason, WS-Trust
presents an overview of these standards. defines a protocol for allowing a client to contact an authority,
trusted by the service provider, to request the token. Such an
A. Standard protocols for Web services security authority is defined as a Security Token Service (STS). An
STS, on his turn, can define the requirements which clients
SOAP Web services can exploit the SOAP header as an
have to satisfy to obtain the release of a token. As a STS is
extensible container for message metadata, which provides
responsible for releasing those tokens, it is also known as a
developers with a set of options also covering the most typical
“token issuer”.
security issues. The so-called WS-* specifications are designed
in order to be composed with each other. WS-Security supports
the definition of security tokens inside SOAP messages and
uses XML Security specifications to sign or encrypt those
tokens or other parts of a SOAP message. It provides a level of
abstraction which allows different systems, using different
security technologies, to communicate securely using SOAP in
a way which is independent from the underlying transport
protocol. This level of abstraction allows developers to use
existing security infrastructure and established industry
standards for authentication, encryption and signature, but also
to incorporate new security technologies. Other specifications
provide additional SOAP-level security mechanisms.
WS-SecureConversation defines security contexts, which can
be used to secure sessions between two parties. WS-Trust
specifies how security contexts are issued and obtained. It
includes methods to issue, validate, renew and forward security
tokens, to exchange policies and trust relationships between
different parties. WS-Policy allows organizations to specify
various requirements and qualities about the Web services they Figure 1. WS-Trust architecture
expose. This specification provides a general purpose model
and the corresponding syntax to describe the requirements and In Fig.1, arrows represent possible paths of communication
constraints of a Web service as policies, using policy among the Requestor (client), the Web service Provider, and
assertions. WS-SecurityPolicy is based on the structure of the STS. The Requestor contacts the STS for receiving a
WS-Policy and allows an entity to define, through a set of token. The STS has the duty to verify that the Requestor
policy assertions, its own security constraints and possess the necessary attributes for obtaining a token. In the
requirements. Moreover, a set policy subjects can be associated case if the policy of the STS is satisfied, the STS releases a
with each specified assertion. WS-SecurityPolicy allows a Web token. At this point, the Requestor can send a message to the
Service to define a set of assertions, and thus its own security Web service Provider, attaching the obtained token.
requirements, using a standard and interoperable format [8].
The security token released by the STS must have some
Apart from WS-* specifications, additional formats and features, in particular: (i) being verifiable as effectively
protocols are being defined by OASIS, to provide a higher released by the STS, and (ii) effectively authorizing the
level of interoperability among services. The eXtensible requester to the use of some services. These features depend on
Access Control Markup Language (XACML) is a language for the type of token being released: various technologies may be
specifying Role- or Attribute-Based Access Control policies. used to implement the token, such as X.509 and SAML. SAML
The Security Assertion Markup Language (SAML), in is well fit for this scenario as it provides a secure way to make
particular, is an open XML-based format to convey security assertions about some subjects and their attributes. Otherwise
information associated with a principal. The generic structure these features may be guaranteed on the basis of a previous
of a SAML assertion is very similar to what is usually called a agreement, i.e., a secret, shared between the Web service and
“digital certificate”, i.e., an issuer attests some properties about the STS bound to the service. In fact, an STS can be a
a subject, defines the validity limit of the claim, and digitally platform-level Web service, bound to one or more Web
signs the document to prove its authenticity and to avoid services, for which it plays the role of a trusted authority. A
tampering. SAML itself deals with three different kinds of Web service may trust the signature of the STS, or it may
assertions: (i) authentication, (ii) attribute, and (iii) request an STS to validate the token, or validate it in
authorization decision [8]. autonomously.
The WS-Trust standard [11] defines mechanisms for A Requestor may be informed about the necessity to use a
mediating trust relations among entities in the context of Web security token released by an STS, as the needed Web service
Services. It considers a security model in which a Web service can publish a policy where a certain IssuedToken is requested.
The interaction between a client and an STS occurs through a In this work, we propose a generic protocol for ATN. We
request-response protocol. decided to use some elements already proposed in [9], when
possible. However, we organized the protocol and the content
In particular, a RequestSecurityToken is used to request a schemas to better distinguish the two fundamental phases of
token, and a RequestSecurityTokenResponse for responding to the negotiation: (i) the initialization, and (ii) the real exchange
the request. Each request must be associated with an action of credentials and policies.
which identifies the possible actions to request to an STS, as
defines in the WS-Trust standard: to release, renew, cancel or In the initialization phase, the parties use an extensible
validate a token. The requestor can also add claims, expressed TNInit element in a single turn of messaging. It contains
in a certain “dialect” depending on the application. The information useful for defining the parameters of the following
requestor may also specify a service which the request applies negotiation, and for verifying if there is the necessary
to, if the STS is associated with multiple Web services; in this compatibility, before beginning a real negotiation. A TNInit
case, the exact endpoint reference of the Web service has to be element can contain: a SignatureMaterial, for proving the
specified. possession of a private credential; a StrategyFamily, for
identifying a supported family of strategies; a TokenFormat, for
The response may convey a token through a specifying the supported type of security token.
RequestedSecurityToken element. Additionally, it may convey
other proofs through an RequestedProofToken element, In the negotiation phase, the parties use an extensible
containing data which the Requestor may use to demonstrate to TNExchange element. It can contain PolicyCollection and
be authorized for using the token. For example, it may contain TokenCollection elements, for transporting policies and
a secret encrypted with the public key of the Requestor. credentials, respectively, disclosed to the other party during the
negotiation. Moreover, it can contain TokenType,
B. A Generic ATN Protocol for Web Services RequestedSecurityToken and OwnershipProof, for conveying
the requested token and other associated proofs.
An STS is normally integrated into a system using a single
round of messages, i.e. a RequestSecurityToken (RST), sent
from the requestor to the STS, followed by a IV. IMPLEMENTATION OF A PRACTICAL STS FRAMEWORK
RequestSecurityTokenResponse (RSTR), sent from the STS to Following the design of a generic Trust Negotiation
the requestor. However, in some scenarios, more steps may be protocol for Web services, a practical implementation has been
needed before a token is obtained. In fact, the WS-Trust realized. At this step, it is mainly an experimentation
standard foresees the extension of this basic mechanism, framework, for testing both the functionality and performance
named “negotiation and challenge framework”, which is of the proposed protocol. However, part from prototype
depicted in Fig.2. services and clients, most of its components are reusable for
creating open SOA-based applications, especially in the case of
dynamic service selection and composition.
The framework is available as part of the open source
dDelega project [12], at https://github.com/tomamic/dDelega.
dDelega is the result of ongoing work started with the
development of a security layer for JADE, one the most
widespread FIPA-compliant multi-agent systems [13].
In particular, it integrates a trust engine, in compliance to
WS-Trust specifications. It also integrates an advanced rule
engine for compliance checking against disclosure policies.
These engines can be used by parties in a WS environment, by
means of translator components that has been realized, in order
to complete the integration. At a more basic level, the
implementation exploits a number of frameworks developed
under the Apache Foundation umbrella, including Axiom,
Figure 2. WS-Trust - Negotiation and challenge framework Axis, Rahas, Rampart.
The message exchange starts with a RST for requesting the A. Integrating a modular trust engine
token, then an arbitrary number of RSTR messages can be
exchanged between the Requestor, or other entities, and the The trust engine must be able to evaluate which policies
STS. Those RSTR messages may convey any additional and credentials have to be inserted into the message at each
information needed for completing the transaction, before round of the negotiation, on the basis of current state of
finally transmitting the token. The WS-Trust standard defines negotiation and policies and credentials received at the
some elements for proposing a “challenge” the other end, previous round.
including: SignChallenge, BinaryExchange, TrustBuilder2 (TB2) is a framework for trust negotiation,
KeyExchangeToken. However, it does not specify how to use developed for providing a flexible and extensible tool in the
such elements, or even other arbitrary elements, in a context of research about this problem area. It is the second
transaction. For example, Policy elements may be used by both main version of the TrustBuilder tool and it has been developed
parties to exchange their respective policies. at the DAIS (Database and Information Systems) Laboratory of
the University of Illinois [14].
Figure 3. System architecture
TrustBuilder2 has not been realized for usage in the context After this phase, the main negotiation rounds take place,
of Web services, however his modular structure allows it to be characterized by the exchange of data structures called
extended for: (i) using different policy languages, (ii) TrustMessage, i.e. objects containing policies and credentials
implement different negotiation strategies, (iii) and provide to exchange during the negotiation.
support for different types of credentials.
In this research work TrustBuilder2 is used as a trust engine
In particular, after a proper translation we defined, it is able for automated trust negotiation. A mechanism has been realized
to evaluate policies expressed according to the for translating “TB2 messages”, i.e. InitBrick and
WS-SecurityPolicy language. Starting from received policies TrustMessage objects, into “WS-Trust messages”, i.e. RSTR
and credentials, it is able to analyze them and take decisions messages containing TNInit and TNExchange elements, which
about which credentials and policies to disclose, according to are exchanged in the context of a “negotiation and challenge
the chosen negotiation strategy. The framework uses a policy framework”, as defined by WS-Trust.
compliance checker, which has the duty of finding one or more
minimal sets of credentials satisfying a given policy. In TB2, Policy and credentials are represented as abstract classes
the main components of ATN are represented as interfaces, and credentials in TB2, in such a way to make the tool
which can be implemented and extended to add new independent from the type of policies and credentials used. The
functionalities. They can be distinguished as: authors of TB2 have also implemented the support for X.509
credentials; in fact, the implementation of this research work
• Strategy module: regarding negotiation strategies. uses X.509 credentials. In TB2, credentials are organized in
• Policy compliance checker: regarding the problem of chains; i.e. when a credential, released by an authority, is sent,
finding a set of credentials satisfying a policy. then the whole chain has also to be sent. In fact, TB2 does not
• Query interfaces: used to provide access to resources, process single credentials, but chains of credentials, through
including local policies and credentials. the CredentialChainMediator component, which uses
algorithms to build and validate chains of credentials. This
• Credential chain module: used to build and validate
allows administrators to create decentralized authorities, valid
chains of credentials, during the negotiation process.
for the different parties participating in a negotiation process;
TrustBuilder2 is designed according to a model of moreover, it allows TB2, when processing a chain, to verify the
negotiation with two main phases. The first phase is issuer of a credential released by an entity, starting from the
characterized by the exchange of messages containing data verification of the root certificate of the chain.
structures, called InitBrick, for communicating the information
Moreover, our implementation requires a user to specify,
needed to initialize a negotiation.
though configuration files, information about some
components to be used by a client and a server, with respect to checker with a much leaner code than the Jess policy checker.
TB2 functionalities. This allows users to customize negotiation Moreover, the tool is completely open-source, at the contrary
strategies, types of credentials and policy languages to be used of Jess; it is continuously updated, with the addition of new
in a certain application. The credential loader module can also features, and it has the attentions of a vast and lively
be customized to load particular credentials into the system; it community of developers.
has access to a list of available credentials. The profile
manager module uses the same customization to decide which C. Initial evaluation
class loader to use, according to the type of credentials used by
the PolicyManager. A policy loader contains information for The ATN process, as described in the previous sections,
the PolicyManager, to decide which policy class loader to use. was analyzed from the point of view of performance. The
evaluation regarded the influence of the various components of
the system and the conversions required by those components
B. Using a rule engine as a policy checker for communicating. For this tests, a scenario has been realized,
A fundamental aspect of TB2 is the logic it uses for the in which:
functioning of its compliance checker component. In TB2, the
problem of finding a set of credentials satisfying a policy is • the client requests a token;
reformulated into the so-called “many pattern/many object • the STS sends a policy requesting a chain of
match” problem, i.e., to find the objects matching the given credentials;
patterns. Here, credentials are considered as objects and • the client, on the other hand, protects one of the
policies as patterns, in a problem which can be solved using a credentials in the chain with a policy, which he
production rule engine. The rules of such engines have a discloses to the STS;
standard format, with: an LHS (left hand side), the part of the • then, the STS discloses the credentials satisfying the
rule defining the conditions; and an RHS (right hand side), the client's policy;
part of the rule defining the action to perform in the case when • thus, the client discloses the credential chain initially
the conditions of the LHS are satisfied. requested by the STS;
TB2 includes the Clouseau component, that is an expert • finally, the STS sends the requested token.
system using the Jess (Java Expert System Shell) rule engine, Including the initialization phase, the whole process takes 4
which provides APIs for integration into a Java application. rounds, in which both the client and the STS send a message to
The rules, representing the policies of a trust negotiation the other party.
process, define constraints on credentials. Jess implements the
Rete algorithm [15], which allows to solve the “many 4 rounds, with Enc & Sign 6.0s
pattern/many object match” problem. Using an engine of this 4 rounds, w/o Enc & Sign 4.8s
kind in a trust negotiation process requires to introduce rules
for representing policies, which specifies the patterns. The 3 rounds, w/o Enc & Sign 4.0s
knowledge base, instead, is determined by acquired credentials. 3 rounds, 1 credential requested by STS 3.0s
An inference can be realized by finding a set of credentials 4 rounds, TB2, no WS 1.2s
satisfying the policy, which is exactly the duty of the policy Table 1. Initial performance results
checker in TB2. Thus, a policy checker is nothing more than an
expert system based on production rules. As shown in Tab.1, the execution times vary around a mean
value of 6 seconds, including the signature and encryption of
Jess does not support natively any object for representing SOAP messages, and 4.75 seconds without any signature and
credentials or policies. Instead, to use credentials in Jess and to encryption. Considering instead a minimal negotiation process
insert them into its working memory, it is necessary to define of three rounds, the execution time is around 4 seconds.
their format explicitly. Then, through JessComplianceChecker Decreasing the credentials required by the policy from 3 to 1,
class, an assert command must be constructed and executed. the execution time does not vary proportionally, but it is
This requires quite cumbersome code, for constructing thse reduced only by around 1 second. This means that a significant
command as an “assert(...)” string, starting from the object part of the computation load is absorbed by TB2, for the
representing the credential. evaluation of policies, in addition to the basic workload
Instead, in this work we have customized the imposed by the WS-* stack [17][18].
TrustBuilder2, extending it for using a different rule engine as These qualitative results are in accordance with those
a policy checker. In particular, we used the Drools rule engine conducted by some authors of TB2 [19], which report that
[16] for the policy checker component instead of Jess, almost half of the total time of execution is used by the policy
supported by the currently available version of TB2. Drools is checker. Another significant comparison is with the execution
based on the so-called ReteOO algorithm, i.e., an adaptation of of a negotiation using only the TB2 tool, in which a TB2Client
the Rete algorithm for object oriented systems. In Drools there and a TB2Server communicate directly, through a dedicated
are two main storage areas: a Production Memory, where rules socket, without any conversion, signature or encryption: in the
are stored, and a Working Memory, where known facts are same scenario with 4 rounds, as described above, the process
stored. For trust negotiation, the Production Memory can be takes 1.2s in TB2, against the 6s required by the whole Web
used for storing the policies as rules, while the Working services infrastructure implemented in this work.
Memory can be used for storing the credentials as facts. An
important advantage with respect to Jess is that facts in Drools It is worth noting that more efforts may be dedicated to the
are represented as Java objects, which can be put directly into optimization and fine tuning of various components the system.
the Working Memory. This has allowed us to develop a policy Thus, performance may be improved in many aspects. For
example, the inclusion of policy statements into Drools is now [9] Lee, A. J., & Winslett, M. (2008, June). Towards Standards-Compliant
a process involving various steps and conversions. In future Trust Negotiation for Web Services. In Trust Management II:
Proceedings of IFIPTM 2008 (Vol. 263, p. 311). Springer.
releases of the framework, this process will be streamlined,
enabling a more direct inclusion of policies and improving [10] Yu, T., Winslett, M., & Seamons, K. E. (2001). Interoperable strategies
in automated trust negotiation. In Proceedings of the 8th ACM
efficiency. conference on Computer and Communications Security (pp. 146-155).
[11] Nadalin, A., Goodner, M., Gudgin, M., Barbir, A., & Granqvist, H.
V. CONCLUSIONS (2009). WS-Trust 1.4. OASIS (February 2009).
[12] Tomaiuolo, M. (2013). dDelega: Trust Management for Web Services.
This paper presented the design and implementation of a International Journal of Information Security and Privacy (IJISP), 7(3),
generic Trust Negotiation framework for Web services. It 53-67. ISSN:1930-1650.
allows users to create trust automatically, by incrementally [13] Poggi, A., Tomaiuolo, M., & Vitaglione, G. (2005). A Security
disclosing credentials. Modular applications can integrate Infrastructure for Trust Management in Multi-agent Systems. Trusting
services provided in an open environment, on the basis of Agents for Trusting Electronic Societies, Theory and Applications in
peer-to-peer trust relationships. Interoperability among such HCI and E-Commerce, LNCS, vol. 3577, R. Falcone, S. Barber, and M.
services is guaranteed by the conformance to standard P. Singh, Eds. Berlin, Germany: Springer, 2005, pp. 162-179.
protocols for Web services. The realized ATN system is [14] Lee, A. J., Winslett, M., & Perano, K. J. (2009). Trustbuilder2: A
composed of various components and requires various format reconfigurable framework for trust negotiation. In Trust Management III
conversions for messages, policies and credentials. For these (pp. 176-195). Springer Berlin Heidelberg.
reasons, the complete execution of a negotiation process is [15] Forgy, C. L. (1982). Rete: A fast algorithm for the many pattern/many
quite costly and imposes a significant computational overhead. object pattern match problem. Artificial intelligence, 19(1), 17-37.
Thus, it is advisable to release tokens which can be used for [16] Sottara, D., Mello, P., & Proctor, M. (2010). A Configurable Rete-OO
Engine for Reasoning with Different Types of Imperfect Information.
accessing a number of cohesive services in a given time IEEE Transactions on Knowledge and Data Engineering, 22(11),
interval, without repeating the negotiation. 1535-1548.
Besides using the framework in generic Web-based [17] Novakouski, M., Simanta, S., Peterson, G., Morris, E., & Lewis, G.
applications, further research work will also investigate the (2010). Performance analysis of ws-security mechanisms in soap-based
web services (No. CMU/SEI9-2010-TR-023). Carnegie-Mellon
possibility of using an Automated Trust Negotiation protocol in University, Software Engineering Institute.
distributed social platforms [20]. In fact, especially in the case
[18] Rodrigues, D., Pigatto, D. F., Estrella, J. C., & Branco, K. R. (2011).
of location-aware applications, unknown users may need to Performance evaluation of security techniques in web services. In Proc.
establish some level of trust before interacting, when meeting of the 13th International Conference on Information Integration and
at a certain place or at a certain event. Web-based Applications and Services (pp. 270-277). ACM.
[19] Lee, A. J. (2008). Towards practical and secure decentralized
In this sense, the framework described in this work will attribute-based authorization systems. ProQuest.
provide a solid ground for further analysis in different
[20] Franchi, E., Poggi, A., Tomaiuolo, M. (2013). Supporting Social
application scenarios, above all for its generality and Networks with Agent-Based Services. International Journal of Virtual
modularity, which permit to exploit a powerful trust engine and Communities and Social Networking (IJVCSN), 5(1), 62-74.
a well known rule engine with very different kinds of protocols ISSN:1942-9010.
and credentials.
REFERENCES
[1] A. Poggi. Developing Ontology Based Applications with O3L. WSEAS
Trans. on Computers 8(8): 1286-1295, 2009.
[2] Winsborough, W. H., Seamons, K. E., & Jones, V. E. (2000). Automated
trust negotiation. In DARPA Information Survivability Conference and
Exposition, 2000. DISCEX'00. Proceedings (Vol. 1, pp. 88-102). IEEE.
[3] Winslett, M., Yu, T., Seamons, K. E., Hess, A., Jacobson, J., Jarvis, R.,
& Yu, L. (2002). Negotiating trust in the Web. Internet Computing,
IEEE, 6(6), 30-37.
[4] A. Negri, A. Poggi, M. Tomaiuolo, P. Turci. Dynamic Grid Tasks
Composition and Distribution through Agents. Concurrency and
Computation: Practice and Experience, 18(8):875-885, 2006.
[5] Venanzi, M., Piunti, M., Falcone, R., & Castelfranchi, C. (2011, July).
Facing openness with socio-cognitive trust and categories. In
Proceedings of the Twenty-Second international joint conference on
Artificial Intelligence – Vol. One (pp. 400-405). AAAI Press.
[6] Li, N., Mitchell, J. C., & Winsborough, W. H. (2005). Beyond
proof-of-compliance: security analysis in trust management. Journal of
the ACM (JACM), 52(3), 474-514.
[7] Yu, T., Ma, X., & Winslett, M. (2000, November). PRUNES: an efficient
and complete strategy for automated trust negotiation over the Internet.
In Proceedings of the 7th ACM conference on Computer and
communications security (pp. 210-219). ACM.
[8] Bertino, E., Martino, L. D., Paci, F., & Squicciarini, A. C. (2010).
Standards for web services security. In Security for Web Services and
Service-Oriented Architectures (pp. 45-77). Springer Berlin Heidelberg.