Arab Academy for Science, Technology & Maritime Transport
Abstract
Representational State Transfer (REST) [1] is an architectural style for building large-scale distributed information networks, the most famous of these being the World Wide Web [12]. RESTful web services have an issue with its security model, lacking a standard way to secure it, in the same time its security relies in the underlying protocol. [8]
Existing solution to secure it, is to use https instead of http, the issue with that approach is that , this is a transport layer protocol so it doesn’t provide authentication or authorization yet it secure the end to end channel between both parties.
In the proposed solution, Diffie–Hellman key exchange is used to generate a session key to be used within the interactions to secure the requested resources and encrypt the resource representation or parts of it; in this solution a pluggable filter is introduced with the advantages of avoid any change in the existing code and secure only the needed resources.
The suggested solution protect the resources and provide both authentication and authorization, this would fix the security issues related to RESTful web services but results in stateful filter that contradict with the basic concepts of this technology.
Keywords
RESTful Web Services; Diffie–Hellman Key Exchange; Web Services Security.
I. Introduction
RESTful web services emerged as a scalable way of doing web services yet there is not mature as the traditional SOAP-based web services that has a lot of security standards including WS-SE??.
Some suggested solutions to secure the RESTful web services includes using https instead of http, the issue with that approach is that , this is a transport layer protocol so it doesn’t provide authentication or authorization yet it secure the end to end channel between both parties, anther way is to send authentication data with each request, this could provide authentication , but subjected to other attacks in case as man-in-the-middle attack, another way is to send a token granted from token generating service like OAuth[11] this have the same previous solution [9] most successful if used in trusted environment like organization intranet [10].
In the proposed solution, Diffie–Hellman key exchange is used to generate a session key to be used within the interactions to secure the requested resources and encrypt the resource representation or parts of it; in this solution a pluggable filter is introduced with the advantages of avoid any change in the existing code and secure only the needed resources.
II. Background
REST refers to Representational state transfer, a terminology first mentioned by Fielding, Roy Thomas in his Doctoral dissertation “Architectural Styles and the Design of Network-based Software Architectures” in the year of 2000. [1]
The concept is known since the evolution of the internet but it was first time to be described and this make sense as Fielding was one of the authors of http protocol specifications (1.0 and 1.1)[4][5], the 1st interest in this architecture appears once the programming languages support the REST feature; Java in 2007/2008 [2]
In spite the wide adaptation of RESTful web services in the public exposed services; it is still has some areas that need to be enhanced in compare to SOAP-based web services where there are a lot of existing standards referred as WS-* standards (e.g. WS-Addressing, WS-Security); one of these areas is the web service security where it lack any standard way to implement it and actually the only existing standard way is to use https protocol as a transport layer security protocol.
For message-level security, it’s using HTTPS seems enough, but for other capabilities such as signatures, encryption, or federation cannot be supplied by HTTP alone. [3]
One existing solution is to have authentication token by a secure token service then use the token to access this RESTful web services. [3] The standard description of the RESTful web services is Web Application Description Language (WADL). [6]
Diffie–Hellman key exchange method - first published by Whitfield Diffie and Martin Hellman in 1976 - allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher. [7]
III. Proposed Model
The proposed solution here utilize the Diffie–Hellman key exchange to generate a session key using the normal http protocol without the need for any secure tunneling so the client and the server can both have the same key and use it to encrypt the parts the need to be secure in the REST calls.
For example the resource URL can be encrypted , and only the server can identify it using the session key, also the returned resource could be also encrypted (partially or completely) so only the client requested this resource can decrypt it using the session key.
This is implemented using intercepting filter that authorize the client and validate the resource access rights, the main advantage of being implemented as a filter is that it can be configured per the needed resources so you can still provide some without security, also no need to change the RESTful WS implementation as it would be just another layer over it so its pluggable, and you don’t need the code to be repeated being centralized location for these requests.
The server will invalidate the key after a configurable time (session time) in that case the client is required to generate a new session key to interact, this filter here represents the only part of the system that behave as stateful not stateless as the RESTful web services behavior.
Figure 1: Represents the different component in the system and different message types between the client and our proposed RESTful System.
As shown in the above diagram the system has client data represents the needed information which are the identification and 2 selected values to generate the session key, another component to authorize each user to different resources, describes which component could be interacted by the client and to which level (read, create, update and delete).
The client can interact in 2 steps 1st to get a session key then to manipulate the resources (step 1 and 2 in the diagram), of course the session key will expire after certain period of time so the client call need to be wrapped to get a new session key if the call return session key expired exception or to have some sort of scheduler run to get a new session key, the session key here represent a resource in the system like any other resources so the user need to interact with it on this concept; it is a good way to increase the security over the connection as without the need of https the channel is dynamically secure, yet the user can choose if the resource is needed encrypted or not according to the needs plus the ACL that determine additional attribute if this resource is allowed to be interacted non-encrypted.
IV. Results
The system is used to control integration layer between the 2 tiers , the system provide a good way to secure RESTful web services without the need to use https, the security is dynamically obtained using a session key generated by Diffie–Hellman key exchange method, also the system provide a way to authorize the access on different resources.
The system flexible enough to assign different access privileges to each client according to the authorization level assigned to this client, in the same time it is pluggable in any existing system as it is implemented using pluggable filter.
The following table contains comparison between the proposed system, standard REST system and securing it using https protocol.
Non-secure REST Secured using https Proposed system
Authorization N N Y
Secure resources N Y Y
Secure URL/URI N N Y
Secure other protocols Y N Y
Table 1: Shows the comparison between using the proposed system, non-secure REST and securing it using https.
The system is composed of 3 main components: filter that control the access of these resources, access control list to apply all authorization roles and client data for authenticating the users, these authentication data need to store the 2 numbers shared between the client and the service provider, they are some sort password of the clients.
The system flexibility allows the usage of the implementation for selected resources only so it doesn’t impact the performance for the resources that do not need any security measures.
V. Conclusion
The proposed system cover some deficiencies in REST non-secure standard and provide some benefits include 1) securing the requested URL, 2) provide authorization through Access Control List (AOL) over resources, 3) secure the resources representation between the client and server being encrypted by the session key, 4) the system is implemented using pluggable filter so it can be easily switched on/off or added to any existing solution without much efforts.
References
[1] Fielding, Roy Thomas. “Architectural Styles and the Design of Network-based Software Architectures”. Doctoral dissertation, University of California, Irvine, 2000.
[2] Java Specification Request Web Site. http://jcp.org/en/jsr/detail?id=311 (Retrieved on 9th December, 2011).
[3] Paul Adamczyk, Patrick H. Smith, Ralph E. Johnson, Munawar Hafiz, REST and Web Services: In Theory and In Practice.
[4] Hypertext Transfer Protocol -- HTTP/1.0. http://tools.ietf.org/html/rfc1945 (Retrieved on 9th December, 2011).
[5] Hypertext Transfer Protocol -- HTTP/1.1. http://tools.ietf.org/html/rfc2616 (Retrieved on 9th December, 2011).
[6] Web Application Description Language (WADL). http://www.w3.org/Submission/wadl/ (Retrieved on 9th December, 2011).
[7] Martin E. Hellman et al. Cryptographic apparatus and method 1976.
[8] Why REST security doesn't exist - Chris Comerford and Pete Soderling. http://www.computerworld.com/s/article/print/9161699/Why_REST_security_doesn_t_exist?taxonomyName=Security&t
axonomyId=17 (Retrieved on 26th December, 2011).
[9] Securing REST Web Services With OAuth http://developers.sun.com/identity/reference/techart/restwebservices.html (Retrieved on 26th December, 2011).
[10] Eric Brachmann, Gero Dittmann ,Gero Dittmann. Simplified Authentication and Authorization for RESTful Services in Trusted Environments, August 2011.
[11] Eran Hammer-Lahav. The OAuth 1.0 protocol. RFC
5849, IETF, April 2010.
[12] Jacobs, I., Walsh, N., eds.: Architecture of the World Wide Web, Volume One, December 2004.
No comments:
Post a Comment