Peer-to-Peer Delegation for Accessing Web Services Michele Tomaiuolo, Paola Turci Dipartimento di Ingegneria dell’Informazione Università degli Studi di Parma, Parma, Italy {michele.tomaiuolo, paola.turci}@unipr.it Abstract — Hierarchical collaborations between cooperative, encryption specifications, defines a standard way to secure rational agents are quite naturally achieved through goal SOAP messages, independent from the underlying transport delegation. In the context of a service-oriented architecture, protocol. As far as the REST-style is concerned, the security agents responsible for workflow management can subdivide their model is not as highly-developed as the security model for goals in sub-goals, generate a utility function from each sub-goal SOAP. Nevertheless, in both cases the focus is on individual and set up a negotiation process with the agents associated to one Web services and the access issues in composed services or in or more Web services and responsible for the interaction with the case of the presence of intermediaries between the requester them. However, such delegations cannot come into effect unless and the resources have not been taken into consideration. The they are associated with a corresponding delegation of privileges, problem becomes more complex when the use of workflows which are needed to access some resources and achieve desired goals. In this paper we present a security mechanism for involves many layers of services. SOAP-style and REST-style Web services that allows the Let us consider, for instance, a heterogeneous society of distribution of the delegation of access rights among different agents, where different members have different internal services and clients. complexity. In such a heterogeneous society, hierarchical collaboration between reasoning capable agents is achieved Security; delegation; authorization; Web services. mainly through goal delegation. From the perspective of this example, the most interesting types of agents composing the I. INTRODUCTION society could be: the WS-manager agent and the workflow A number of architectures and systems are being proposed manager agent. Each WS-manager agent is associated to one or as a ground for improved interoperability among diverse more Web services and is responsible for the interaction with systems, mainly exploiting the idea of a service-oriented them. Workflow managers have the goal of supporting users in architecture. There are two preferred ways of realizing a the process of building workflows, composing external Web service-oriented architecture based on Web services, i.e. services and monitoring their execution. The workflow SOAP-style and REST-style. REST Web Services have been manager agent assumes the role of the delegate agent in a goal enjoying increasing popularity in the last years. The rationale, delegation protocol, subdivides its goal in sub-goals, generates upon which REST is based, is quite simple, i.e. the use of long- a utility function from each sub-goal and sets up a negotiation established Web technologies instead of new standard process with the WS- manager agents. In such a scenario, these specifications. In particular, REST-style Web services are a delegations cannot come into effect unless they are associated design paradigm in which web services are viewed as resources with a corresponding delegation of privileges, which are and can be identified by their URLs. On the other hand, SOAP- needed to access some resources and complete delegated tasks, style Web services may be more appropriate when a formal or achieve desired goals. contract must be established to describe the interface offered by In this paper we present a security mechanism for SOAP- web services or when developers must address complex style and REST-style Web services that allows the distribution nonfunctional requirements. Therefore, depending on the of the delegation of access rights among different services and particular application scenario, one has to decide the best clients. This paper is organized as follows. In Section 2 we give approach to use. background information on WS-* and RESTful Web services The adoption of a service-oriented paradigm based on Web with particular attention to security issues. The third section services has definitely many benefits, but security is still a briefly discusses the related work. Then, in Section 4, the great concern. A lot of efforts, by various standards groups basics of peer-to-peer delegation are introduced and in the such as W3C, WS-I, OASIS, etc. have been devoted to web following section a generic library and some services service security standards in recent years. A basic way of implementing those basic mechanisms are presented. Finally, achieving security is relying on a secure transport layer, in the last section, some conclusions are drawn about this work. typically HTTPS and TLS. However, a message-level security is required in the case of architectures in which intermediaries II. SERVICES ON THE WEB: SECURITY ISSUES can manipulate messages on their way. This was the rationale REST-style and SOAP-style Web services are not mutually for the definition of new specifications, such as WS-Security exclusive nor is one better than the other. Both are valid [23]. WS-Security, by using the XML-signature and XML- approaches to solving real problems, each with its strengths and weaknesses. The choice of which approach to use should but if advanced functionalities, as those delivered by WS-*, are be based on the characteristics of the application being needed, it is not so simple to extend REST-style Web services developed. in order to support them in an interoperable manner. For less demanding scenarios, both REST and SOAP styles take At a fundamental level the difference between REST-style advantage of the basic guarantees provided by protocols such and SOAP-style Web service is ascribable to the difference as HTTPS and TLS. between resource-oriented and activity-oriented services. Resource-oriented services focus on a collection of resources upon which a set of basic operations can be performed. The III. RELATED WORK operations that can be performed are defined by the HTTP The Web Services access control is already becoming an specification, i.e. retrieving, creating, modifying and deleting important topic of many recent researches. The various security resources. In other words, this means working directly with the standards proposed and most of the studies carried out in the HTTP interface down at the transport layer, rather than context of Web services focus mainly on the access control addressing system-specific interfaces and using messages for policies for single web services [4][5][6]. In particular, in [5] sending the invocation details of Web services. On the other the authors address the problem of securing sequences of hand, an activity-oriented service focuses on actions that one SOAP messages exchanged between web services and their can perform. Actions are the center of the attention, as opposed clients. By constructing formal models they investigate the to resource-oriented services where operations that can be security guarantees offered by the specifications WS-Trust and performed remain basically constant regardless of the type of WS-SecureConversation, which provide mechanisms allowing resources. After all, in the REST perspective the Web is seen as communicating parties to establish shared security contexts and the means for publishing globally accessible resources and for to use them to secure SOAP-based sessions. delivering services to clients, whereas in the SOAP context the HTTP protocol is only exploited as a binding transport protocol A few research works have dealt with security issues and the selection of the operation to be performed is specifyed related to composed services. in the SOAP message. Such differences have obvious She et al. [29] propose a delegation-based security model to consequences on the way security is implemented in the two address problems such as how much privilege to delegate, how approaches to confirm cross-domain delegation, how to delegate additional The Web service specifications (WS-*), taking advantage privilege. The proposed model extends the basic security the SOAP header as an extensible container for message models and supports flexible delegation and evaluation-based metadata, provides developers with a set of optional access control. But all web services participating in this specifications including those which cover the security issues. composition have to agree on a single token-based The WS-* specifications are designed in order to be composed authorization mechanism, i.e. a hierarchical access control with each other. WS-Security provides a level of abstraction framework is provided. which allows different systems, using different security In [9] a delegation framework which allows delegation of technologies, to communicate securely using SOAP in a way access rights in multi-domain service compositions is which is independent from the underlying transport protocol. presented. The approach is based on an abstraction layer, This level of abstraction allows developers to use existing called abstract delegation, which harmonises the management security infrastructure but also to incorporate new security of heterogeneous access control mechanisms and offers a technologies. It provides a set of security features, built on unified user experience hiding the details of different access established industry standards for authentication and XML control mechanisms. Our approach differs from this because encryption and signing, which supports the definition of we consider each service or resource as a trust domain based security tokens inside SOAP messages, the use of XML on a certificate chain access control mechanism. Security specifications to encrypt and sign these tokens and to sign and encrypt other parts of a SOAP message. Recent specifications provide further SOAP-level security IV. DELEGATION mechanisms. WS-SecureConversation defines security The traditional approach for inter-domain security is based contexts, which can be used to secure sessions between two on centralized or hierarchical certification authorities and parties. WS-Trust specifies how security contexts are issued public directories of names [13][14][16]. In contrast with this and obtained. It includes methods to issue, validate, renew and hierarchical approach, other solutions are possible, where the forwarding security tokens, to exchange policies and trust owner of local resources is considered as the ultimate source of relationships between different parties. Finally, WS-Policy trust about them, and he is provided with means to carefully allows organizations, exposing Web Services, to specify the administer the flow of delegated permissions [7][8][18]. Trust security requirements of their services. This specification management principles argue that no a-priori trusted parties provides a general purpose model and the corresponding syntax should be supposed to exist in the system, as this would imply to describe the requirements and constraints of a Web service some “obligated choice” of trust for the user, and without as policies, using policy assertions. choice, there is no real trust. Moreover, the presence of some third party as a globally trusted entity implies that all systems No framework for advanced security, equivalent to that participating in the global environment have to equally trust it. provided by WS-*, has been proposed for REST. The simplicity of REST if compared with SOAP and WS-* stack is Nowadays, new technologies, in the form of protocols and real until it is carried out an ad hoc integration over the Web, certificate representations, are gaining momentum. They allow a different approach towards security in global environments, Access Control. In particular, some authors [12] argue that an approach which is paradoxically founded on the concept of dRBAC should add some new features to previous approaches: “locality”. Federation of already deployed security systems is considered the key to building global security infrastructures. • Third-Party delegations allow some entities to delegate In this way, users are not obliged to adopt some out of the box roles in different namespaces. This mechanism, related to the solution for their particular security issues, to rebuild the whole “speaks for” relationship in the Taos system, does not add any system or to make it dependent upon some global authority, in new functionality, as the same results can be obtained using order to gain interoperability with others. anonymous intermediate roles, but improves the expressiveness and manageability of the system. Instead they are provided with means to manage the trust relations they build with other entities operating in the same, • Valued attributes allow to add attributes and global environment. In the same manner as people collaborate corresponding numeric values to roles. This way, access rights in the real world, systems are being made interoperable in the for sensible resources can be modulated according to some virtual world. Cooperation and agreements among companies attributes. The same result could be obtained by defining and institutions are making virtual organizations both a reality different roles for different levels of access rights, but this and a necessity. But they will never be very successful if would multiply the number of needed roles. existing technologies will not match their needs. • Continuous monitoring allows to verify the actuality of The Simple Digital Security Infrastructure (SDSI) trust relationships. Typically, this feature is based on a [1][15][28], which eventually became part of the SPKI publish/subscribe protocol to advertise the status updates of proposal [10], showed that local names could not only be used relevant credentials, which can be either revocable or short- on a local scale, but also in a global, Internet-wide, lived. environment. In fact local names, defined by a principal, can be guaranteed to be unique and valid in its namespace, only. V. IMPLEMENTATION AND DISCUSSION However, local names can be made global, if they are prefixed In the following the implementation of security with the public key (i.e. the principal) defining them. There's mechanisms for web services, based on peer-to-peer no limitation to the number of subjects (keys or other names) delegation, will be presented. In particular, a generic library which can be made valid meanings for a name. So in the end, a has been developed, which allows issuing and verifying chains name certificate defines a named group of principals. Some of delegation certificates and thus allows associating a authors interpret these named groups of principals as particular request with some roles and permissions. distributed roles [19][20][21]. The case where a group contains Furthermore, a SOAP based security service has been other groups is interpreted as a role-subroles relation. While the developed, responsible for allowing the creation of a security SPKI proposal was based on s-expressions for representing session on a platform, so that a client can send his chain of certificates, the theory on which the proposal is based doesn't delegation certificates just once, and then possibly access the force a particular representation. services provided on that platform. A quite similar service has Recently, the SAML language emerged as the standard for also been developed according to the RESTful paradigm. representing security assertions [24]. Since the specifications Finally, an extension of our delegation framework is proposed, allow a quite wide range of assertion types to be issued, it is with the aim of taking into account the OpenID protocol. also possible to use SAML to represent delegation certificates based on trust management principles and on the SPKI theory. A. Delegation library The generic structure of a SAML assertion makes evident it The first step to develop a security infrastructure for web is very similar to what is usually called a “digital certificate”. services consisted in the realization of a software library Like in every other certificate, an issuer attests some properties implementing core functionalities, i.e. allowing the creation about a subject, digitally signing the document to prove its and validation of delegation certificates and certificate chains. authenticity and to avoid tampering. Conditions can be added This software library can be used to manipulate SAML and to limit the validity of the certificate. As usual, a time window XACML structures. Unfortunately, probably due to the relative can be defined. Moreover, it can be limited to a particular novelty of relevant standards (especially for their latest audience or to a one-time use. Conditions can also be put on versions), the software park is not particularly vast. the use of the certificate by proxies who want to sign more With regards to SAML, the choice falls on the OpenSAML assertions on its basis. library. In fact, while still being in a development phase, it is Being designed to allow interoperability among very the only one supporting all functionalities of SAML 2.0 and, different security systems, SAML offers a variety of schemes above all, allowing the definition of new classes with relative to format security assertions. One interesting possibility is to simplicity. Extensibility is in fact particularly important, in our use a SubjectConfirmation object to represent a subject directly case, to realize a “glue” level between SAML and XACML by its public key, which resembles the basic concepts of SPKI, [25], embodied by the XACMLPolicyStatement element. where, at the end, principals “are” always public keys. About XACML, instead, the choice of Sun's XACML The possibility to link local namespaces in a global scale, Implementation was obliged, in practice, as it is the only valid paves the way for a new paradigm for distributed security. This open source tool to deal with the language. paradigm is sometimes named dRBAC, distributed Role-based Figure 1. Delegation chain Then, it was decided to give a standard structure to our able to obtain all needed policies, to validate the request, the library, realizing its API like a Java security provider. The Java PDP class of XACML uses various finder modules allowing to Cryptographic Architecture (JCA) foresees in fact the retrieve information. It was thus necessary to develop a finder possibility to realize packages, called security provider, which module, called AuthzPolicyFinderModule, which is in charge provide JDK with a concrete implementation of a subset of of retrieving policies from authorization certificates provided Java cryptograohic functionalities. For developers wanting to as parameters. use the library, the main advantage of this choice is the availability of a set of API with a well known and collaudated During the process of creation of a PDP it is possible to structure. Moreover, this will allow the use of certificates and insert additional finder modules. Such modules can be paths which will be realized with normal Java API, without specified in the phase of construction of the duplicating their functionalities. In fact, in principle any AuthorizationEvaluator object and allow to extend the object's component (also external ones), operating on a Java certificate, capabilities to search for information. Moreover, this way it is will be able to operate on a certificate of the new library, too. possible to provide the validation module with a series of local policies which are not stored within SPKI authorization To realize an extension of the Cryptographic Architecture, certificates. first of all it was necessary to extend Java basic data types, which in our case are represented by certificates and paths; The final result of the operation is a list of then engine classes had to be realized, which specify AuthorizationResponse objects, one for each resource which algorithms to be implemented. Finally, a master class for the was asked to be accessed. Each instance contains in its provider had to be implemented, which is necessary to register structure an identifier of the resource which it refers to, a new classes and allow them to be used by Java. decision value and a status code. To represent certificates, Java cryptographic APIs define an B. SOAP services abstact class: Certificate. Within it, all basic methods to The objective of this first sub-project was to create a manage public key certificates can be found. Extending this security mechanism for web services based on the SOAP class, an abstract class has been realized, containing the protocol. The mechanism had to allow the distributed common methods of its derived classes, representing name delegation of access rights among different services and clients. certificates and authorization certificates. Instead of attaching a certificate chain to each service request, a An algorithm to evaluate the correctness of a certificate generic security service was designed. This service had to chain is described in the original SPKI proposal. To this aim, a accept and verify a certificated chain attached to a signed subclass of CertPathValidator had to be developed, authentication request. After a successful authentication, the implementing this validation algorithm (see Fig.1). Parameters client had to be associated with a security session, which it of the validation process are represented as could then mention when trying to access services on a ValidatorParameters objects, containing the list of keys trusted particular platform. The session id had to be obtained by the principal operating the verification, and possibly according to the WS-Trust specifications and it had to be used additional parameters. as a meaningful security token to be associated with WS- Security enriched messages. A further operation to be offered by the library is that of validating a request to access a local resource. The request The sub-project has been implemented using the Axis itself is represented by an instance of the AuthorizationRequest framework, and resulted in a generic authentication service, a interface. Users of the library can provide different dummy service which needs proper authorization to be implementations of the interface, according to their needs. accessed, and a prototype client (see Fig.2). Apart from the request, the algorithm with the list of All three parties are associated with their own couple of authorization certificates to use and the list of trusted keys private and public keys, and can manage chains of delegation needed during the certificate verification process must be certificates encoded as SAML assertions. Moreover all parties provided. Finally, in the case some additional conditions exist, leverage Rampart to generate signed SOAP messages it could be necessary to specify additional parameters for the conforming to WS-Security specifications. verification process. Thus, the project effectively uses a number of technologies The validation happens through the creation of a Policy which have already been tested, and can work together to Decision Point (PDP). The Sun's XACML library provide the realize more complex scenarios than the ones foreseen in their methods for creating such a decision block. However, to be specifications. Figure 2. Using delegation certificates for accessing Web services The realized security Web Service can effectively handle chain of certificates not directly in the request body, but as urls authentication requests, i.e. verify the message signature, verify of signed SAML documents available as resources on the web. the chain of delegation certificates, and eventually generate a This way, the composition of the request is simplified for the security session and return a session identifier to the client. It is user, and moreover this opens up the possibility of renewing not yet associated with an explicit security policy, as defined the delegation certificates automatically, and making the most by the WS-Policy specifications. Instead, the client has to recent issue available in a well known location. possess a-priori knowledge of security requirements. The framework used, for the development of the RESTful The client is built as an example and illustrates all the steps web services themselves, is Jersey. The internal functioning of that a user application has to complete, to use the delegation the services remains the same as in the previous sub-project, mechanism. but the APIs change for adhering to the chosen paradigm. For implementing the dummy service, a Filter was created, which The dummy service, finally, has an associated Axis takes care of contacting the security service and matching the Handler to manage the session abstraction and verify the acknowledged roles with the required permissions. proper authorization before granting access to the service. Under the hood, the handler contacts the security service to receive a list of distributed roles associated with the public key D. Integration with OpenID and session id of the client, and then it uses an XACML policy Installing certificates in a browser is not always possible or to verify the association of the roles with the required desirable. It may be practical for accessing services from a permissions. personal device, but this would limit the integration of the application in the web at large. C. RESTful services OpenID [26] is a decentralized digital identity system, in This sub-project replies in large part the previous one, but which any user’s online identity is given by URL (such as for a in a RESTful environment. The main actors are still a client, a blog or a home page) and can be verified by any server running security service, to handle authentication requests and sessions, the protocol. and a dummy service, which exploits the security service to implement its access control mechanisms (see Fig.2). The main motivation for OpenID is to avoid Internet users, in particular users of blogs, wikis and forums, to create and Some differences, though, derive directly from the different manage a new account for every site they intend to contribute stack of involved protocols. The RESTful approach is much in. Instead, on OpenID enabled sites, users only need to simplified with respect to the SOAP approach. Messages are provide their home url, so that the authentication process can plain HTTP messages, and security is limited to TLS and be completed with their own identity provider. HTTPS. In our scenario, we also introduced some variations, to exploit the specific features of the REST environment. First of A limitation which has been often highlighted, is that all, the client was reduced to a plain web browser, which OpenID does not allow to describe the authentication and login generates all requests and takes care of the cryptography. For mechanism explicitly. When the knowledge of used this purpose, we installed a private/public key pair (encoded mechanism is needed by a relying party, before accepting a into self-signed PKCS#12 certificates) in Firefox and enabled remote authentication notification, it must be obtained by other the not very popular policy of mutual authentication, allowed means. This is the case of access to sensitive data, for example by HTTPS. Another difference we introduced was to send the in the context of e-banking applications, which require the use of strong authentication mechanisms. To solve this issue, the integration of OpenID with SAML has been proposed. In this REFERENCES case, SAML can be used to provide explicit information about [1] Abadi, M. (1998). On SDSI’s Linkd Local Name Spaces. Journal of the authentication context. Computer Security, 6 (1-2), 3-21. [2] Anderson, A., Lockhart, H. (2004). SAML 2.0 profile of XACML. Another limitation is associated with the very idea of Retrieved April 20, 2009, from http://docs.oasis- completely “open” authentication, as in fact a malicious user or open.org/xacml/access_control-xacml-2.0-saml_profile-spec-cd-02.pdf software agent can provide its own authentication server. Thus [3] Aura, T. (1998). On the structure of delegation networks. In Proc. 11th the whole mechanism does not improve security in any way. IEEE Computer Security Foundations Workshop (pp. 14-26). IEEE As a consequence, “open” authentication soon turned into Computer Society Press. federation among authentication domains, using white or black [4] Bertino E., Squicciarini A. C., Paloscia I., and Martino L. (2006). Ws- lists of known OpenID providers. AC: a fine grained access control system for web services. World Wide Web. Vol. 9. No. 2. pp. 143-171. Yet, the main problem is that, even if integrated this way [5] Bhargavan, K., C. Fournet, C., Gordon, A.D., Corin, R. (2007). Secure with SAML or used into a federation of security domains, sessions for web services. ACM Transactions on Information and OpenID still remains focused on authentication, thus its System Security. Vol. 10. Issue 12. 2007. usefulness and applicability is confined to very simple [6] Bhatti R., Joshi J. B. D., Bertino E., Ghafoor A., (2003). Access Control applications, where trust relationships are not built among in Dynamic XML-based Web-Services with XRBAC, In proceedings of The First International Conference on Web Services, Las Vegas. users, with delegation of access rights, but instead based on [7] Blaze, M. , Feigenbaum, J., Lacy, J. (1996). Decentralized trust federation of identity providers. However, in the generic management. In Proc. of the 17th Symposium on Security and Privacy context of service composition, above all in open peer to peer (pp. 164-173). IEEE Computer Society Press. networks, identity information alone (especially if it is [8] Blaze, M., Feigenbaum, J., Ioannidis, J., Keromytis, A. (1999). The provided by some remote host) is not sufficient to take KeyNote Trust-Management System Version 2. IETF RFC 2704, decisions whether to grant access to a local resource or a September 1999. Retrieved April 20, 2009, from service, or not. http://www.ietf.org/rfc/rfc2704.txt [9] Bussard, L., Nano, A., Pinsdorf, U. (2009). Delegation of access rights The next sub-project, which we are working on, in the in multi-domain service compositions. IDIS Journal (Identity in the context of this research deals with the integration of OpenID Information Society), volume 2, n. 2, p. 137-154. Springer Netherlands. into a trust management environment. The goal is to substitute, [10] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., Ylonen, T. in the last ring of a delegation chain, the public key with an (1999). SPKI certificate theory. IETF RFC 2693, September 1999. Retrieved April 20, 2009, from http://www.ietf.org/rfc/rfc2693.txt OpenID url to authenticate the final user of the service. In this [11] Foster, I., Kesselman, C., and Tuecke, S. (2001). The anatomy of the way, on the one hand, the remote identity is associated with grid-enabling scalable virtual organizations. International Journal of distributed roles and thus to local access rights. On the other High Performance Computing Applications, 15(3), 200-222. hand, an identity provider is trusted when it is included into a [12] Freudenthal, E., Pesin, T., Port, L., Keenan, E., Karamcheti, V. (2002). chain of delegation, thus eventually allowing to avoid the dRBAC: Distributed Role-based Access Control for Dynamic Coalition global white and black lists of identity providers. Environments. icdcs, pp.411, 22nd IEEE International Conference on Distributed Computing Systems (ICDCS'02), 2002. This sub-project will have to overcome some problems [13] Gutmann, P. (2004). How to build a PKI that works. 3rd Annual PKI related to the secure communication of the credentials, but R&D Workshop. NIST, Gaithersburg MD. April 12-14, 2004. above all it will have to deal with (and probably live with) [14] Gutmann, P. (2000). X.509 Style Guide. Retrieved April 20, 2009, from important differences between the paradigms: one completely http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt decentralized, the other one based on a unique hierarchy of [15] Halpern, J. van der Meyden, R. (1999). A Logic for SDSI’s Linked names (urls) and on globally trusted third parties to assure the Local Name Spaces. In Proc. 12th IEEE Computer Security Foundations secure communication among all peers. Workshop (pp.111-122). [16] Housley, R., Polk, W., Ford, W., Solo, D. (2002). Internet X.509 Public Key Infrastructure Certificate and CRL Profile. IETF RFC 3280, April VI. CONCLUSION 2002. Retrieved April 20, 2009, from http://www.ietf.org/rfc/rfc3280.txt While the traditional approach for inter-domain security is [17] Khare, R., Rifkin, A. (1997). Weaving a web of trust. World Wide Web Journal, 2 (3), 77-112. based on centralized or hierarchical certification authorities and public directories of names, new solutions are appearing. Trust [18] Lewis, J. Reinventing PKI: Federated Identity and the Path to Practical Public Key Security. 1 March 2003. Retrieved April 20, 2009, from management systems do not assume, a-priori, the existence of http://www.burtongroup.com/ some globally trusted parties. A number of emerging [19] Li, N., Grosof, B. N., Feigenbaum, J. (2003). Delegation logic: a logic- technologies, including SAML and XACML, can enable this based approach to distributed authorization. ACM Transactions on kind of solutions in the context of web services. This work Information and System Security. Vol. 6. No. 1. pp. 128-171. 2003. analyzed the use of peer-to-peer delegation mechanisms in the [20] Li, N. (2000). Local names in SPKI/SDSI. In Proc. 13th IEEE Computer context of SOAP services and RESTful services, using the Security Foundations Workshop (pp. 2-15). IEEE Computer Society relevant standards defined for the two different approaches. Press. The results of this work include a generic library for issuing [21] Li, N., Grosof, B. (2000). A practically implementable and tractable delegation logic. Proc. 2000 IEEE Symposium on Security and Privacy and verifying delegations chains, a security service with a (pp. 29-44). IEEE Computer Society Press. SOAP interface, a security service with a RESTful interface, [22] Moses, T. (2005). eXtensible Access Control Markup Language plus prototype components representing clients and final (XACML) Version 2.0. Retrieved April 20, 2009, from http://docs.oasis- services to be deployed in an open environment. open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf [23] OASIS. Web Services Security: SOAP Message Security 1.1. open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0- http://www.oasis-open.org/committees/download.php/16790/wssv1.1- cd-02.pdf spec-os-SOAPMessageSecurity.pdf. Feb., 2006. [28] Rivest, R.L., Lampson, B. (1996). SDSI - A Simple Distributed Security [24] OASIS Security Services (SAML) TC. http:// www.oasis- Infrastructure. September 15, 1996. Retrieved April 20, 2009, from open.org/committees/security/. http://people.csail.mit.edu/rivest/sdsi11.html [25] OASIS eXtensible Access Control Markup Language (XACML) TC. [29] She, W, Thuraisingham, B, Yen, I-L. (2007). Delegation-based security http://www.oasis-open.org/committees/xacml/. model for web services. In: Proceedings of 10th IEEE High Assurance [26] OpenID (2007). OpenID Authentication 2.0, December 5, 2007. Systems Engineering Symposium (HASE ’07). IEEE Computer Society. Retrieved April 20, 2009, from http://openid.net/specs/openid- p. 82–91. ISBN:978-0-7695-3043-7. authentication-2_0.html [30] Welch, V., Foster, I., Kesselman, C., Mulmo, O., Pearlman, L., Tuecke, [27] Ragouzis, N., Hughes, J., Philpott, R., Maler, E., Madsen, P., Scavo, T. S., Gawor, J., Meder, S., Siebenlist, F. (2004): X.509 Proxy Certificates (2008). Security Assertion Markup Language (SAML) V2.0 Technical for Dynamic Delegation. Proceedings of the 3rd Annual PKI R&D Overview. Retrieved April 20, 2009, from http://www.oasis- Workshop. Gaithersburg MD, USA, NIST Technical Publications.