REST is an established approach for designing distributed applications and service systems that scale at large. This is especially true for the Web while other domains are following likewise. At the same time, the areas of adoption increase in criticality, making the need for appropriate security measures a necessity. The application of transport-oriented security is by far not sufficient and needs to be supplemented by adjacent message-oriented security mechanisms.
In the latter respect, REST behaves very specific in comparison to existing approaches such as SOAP in the Web Services domain. This renders a straightforward adoption of available schemes and technologies from this domain infeasible. This is due to REST being an abstract architectural style on the one hand, that can be applied to many distinct technologies and environments. On the other hand, the particularities of REST demand for tailored approaches and schemes in order to not contradict with the REST constraints.
The introduced methodology marks an important step towards a structured and controlled procedure for developing appropriate security means for REST-based service systems and applications. The practical applicability of the introduced methodology has been proven by an adoption of it to authentication. The introduced generic REST message authentication scheme has then been instantiated to the REST-ful protocols HTTP and CoAP. A comparison with the current state of the art revealed that the available technologies are inhomogeneous and contain many vulnerabilities or do not comply with the REST constraints. This further emphasizes the need for a general and methodical approach towards REST-Security as has been proposed by this paper. Finally, an initial attempt towards REST message confidentiality is introduced discussing requirements and specifics to be considered while developing the complete picture of a general REST message security framework.
More research and development efforts in REST-ful message security are required in order to reach the necessary understanding of an adequate REST-Security defined at the proper abstraction layer while considering the specifics of REST. This is especially essential, since message security for REST-based service systems builds the foundation of many high-level security components (see Figure2.5). Moreover, a stable and robust REST-Security cannot only set the scene for a mature service security stack, but it can also enhance available REST-based security technologies including OAuth [Har12] and OpenID Connect [Sak+14], which still suffer from many vulnerabilities [YM13;SB12].
Future work will focus on elaborating the REST-Security framework in the light of aspects such as performance and scalability. This includes the cacheablity of protected REST-ful messages.
Moreover, concepts that enable intermediate systems transforming signed and encrypted REST messages will be studied as well. This is an important feature in a REST-ful architecture, since transforming the content of a message is an essential property of the layered system constraint.
Chapter 3
On the Security Expressiveness of REST-based API Definition Languages
Summary of this publication
Citation H. V. Nguyen, J. Tolsdorf, and L. Lo Iacono. On the Security Expressiveness of REST-Based API Definition Languages. In: International Conference on Trust and Privacy in Digital Business (TrustBus). 2017. URL:https://doi.org/10.1007/978-3-319-64483-7_14 Status of Paper Published
Type of Paper Research Paper (Conference) Ranking CORE: B, Microsoft Academics: C
Aim This paper provides a systematic analysis of fifteen service description languages with a specific focus on their ability to express security policies.
Methodology The evaluation of the service description languages is based on five criteria: (1) the ability to describe security schemes via native service description elements, (2) the set of security schemes which can be defined by default, (3) the ability to extend the default set of security schemes, (4) the approach for defining the semantics of not natively supported security schemes, (5) available work extending the service description language with additional security description elements.
Contribution The obtained results reveal substantial limitations in all analyzed specification languages. The detected shortcomings motivate the need for more profound research to establish service description languages as a reliable approach for describing REST-based security schemes.
Co-authors’ contribution See Paper 2 in Section1.1.1.
3.1 Introduction
The Service-Oriented Architecture (SOA) [Erl07] paradigm defines an architectural principle for implementing interconnected software systems via service orchestration or service choreography respectively. Contemporary business applications [LRS02] are greatly relying on this paradigm.
It provides the foundation for a dynamic process management, in which service consumers and service provides are able to discover and bind themselves without knowing each other in advance.
In this context, the service description –also known as the service contract– plays a central role when it comes to selecting and invoking services properly [LRS02]. Such service invocations commonly involve the exchange of sensitive information across organizational boundaries and multiple distinct enterprises. The protection of such services and the incorporated datasets is henceforth a necessity, rendering tailored security safeguards mandatory for SOA-based business systems.
Distributed systems following the SOA principles have been most commonly realized by SOAP-based web services [Gud+07]. Here, a service contract is defined by means of the Web Service Description Language (WSDL) [Chr+00]. To declare security, the standardization body OASIS maintains the WS-SecurityPolicy specification [Nad+12]. This security framework includes extensions for describing security requirements and policies in WSDL. As WSDL and the extensions in terms of protection means provided by WS-SecurityPolicy represent a machine-readable data format for describing protected SOAP services, the interface definition language is often used by developers for automatic code generation. This facilitates the proper invocation of services as well as implementation of security properties. On the other hand, it reduces the likelihood of developers for making programming mistakes.
Over the last years, web services have been deployed following the architectural style Represen-tational State Transfer (REST) [Fie00]. One measure of how the architectural style influences contemporary service systems is an analysis of the platform ProgrammableWeb which has been conducted by the authors of this paper. This evaluation reveals that around 76% of 15,000 analyzed APIs are REST-based. In contrast to SOAP, the widespread usage of web services following the REST principles is, however, lacking on a standardized language for defining the service contract and security policies in particular. The missing technical foundation for describing REST-based web services in a machine-readable form, hinders the automatic dis-covery of services. Moreover, it increases the effort of implementing and testing the service invocations as automatic code generation is not supported. This induces a higher probability of producing insecure code as exemplified by Sun and Beznosov [SB12] in terms of the widely adopted authorization framework OAuth [Har12].
With the aim of establishing a REST-based counterpart to WSDL, several description languages for REST-based web services have been proposed. However, the languages’ abilities to de-scribe REST-based web services are very diverse. This paper analyzes the currently available description languages with the focus on the ability to declare required security policies and protection means. Section3.2lays the foundation for a basic understanding of the architectural style REST and thereby briefly recaps its key properties and constraints. Even though REST is still missing a standardized and mature security framework, a set of security mechanisms have become well-established and are presented in the Section3.3. Based on this background, Section 3.4evaluates the features and abilities of available service description languages for REST-based web services in respect to their security expressiveness. The findings are discussed in Section 3.5and Section3.6concludes this paper with an outlook on future research challenges.