Following sections describe requirements, predictions and hypothesis that will be used to guide us through the development process and evaluate the final product.
2.1 Requirements
There is a set of absolute requirements that we feel should be fulfilled in order to support real-life security scenarios. These absolute requirements form the basis and reflect the purpose of our solution.
R1: The very first requirement relates to the formats of RESTful services. By
developing a service in WCF, a RESTful service may offer either XML or JSON format. Therefore, the solution needs to support encryption and digital signatures
for XML and JSON formats.
R2: The second requirement is about full and partial message security. Regarding the nature of systems responsible for message routing, some properties or elements must be in clear text so that the message may be routed to the specific end system.
In some cases the requirement can be to encrypt certain properties and sign those.
In other cases the requirement can be to sign a combination of both encrypted and unencrypted properties. Therefore, the solution needs to support different
combination schemes of encryption and digital signatures for the complete message or selected message properties.
R3: The third requirement is concerned with the overhead upon a RESTful message.
Since a RESTful message is a pure representation of the domain object in one of the supported formats, the message is easy to read for the humans, especially when compared to SOAP messages. Therefore, when encryption and signature are
applied, the message should not become much larger and should be simple to read.
R4: The fourth requirement relates to the existing RESTful projects. The idea is to design and implement our solution in such way that the existing projects developed in WCF may enable message-based security with least effort. Therefore, the
solution must be adaptable with the current RESTful projects developed in WCF.
R5: The fifth requirement is about the interoperability between different platforms and programming languages. RESTful services are based on HTTP which is heavily supported on all popular platforms. Although our solution is to be created on .NET platform, the secured messages may still be downloaded by another platform but the messages may not be understandable. That is why we should strive to secure and structure messages in that way so a solution created on a different platform may understand those messages without much effort. In other words we should make it easier for a developer developing on a non-.NET platform to create a RESTful client or service, and exchange protected messages with RESTful client or services developed on .NET and WCF. This can be achieved by utilizing well-known security mechanisms, implemented on most of the platforms. Therefore, secured messages should implement cross-platform encryption and digital signature
mechanisms in order to be more interoperable.
Finally, it is worth mentioning areas we will not consider in this thesis. The first one is caching which we acknowledge to be important but due to the complexity and time limit this functionality will be ignored. The second area is performance which in our case may be measured by the time it takes to protect a message or the time is takes to
accomplish the message exchange. Although an important parameter in every distributed environment this will not be on our highest priority list but we will always keep it our mind while developing the solution.
2.2 Hypothesis
This thesis defines following hypothesis:
H1: Proposed solution will enable message-level security for RESTful messages on .NET platform.
2.3 Predictions
Given that the requirements are specified and the hypothesis is stated we proceed with the definition of the predictions or success criteria. These predictions will be used to test the hypothesis.
P1: The new artefact, message protection library, later referred to as the new security library, will enable encryption and digital signatures on XML and JSON messages.
P2: The new artefact will support partial encryption and partial digital signature.
P3: The new artefact will enable messages compression and decompression on protected messages so to decrease message size.
P4: The new security solution will be easily adoptable by existing and standard WCF RESTful services.
Since P4 is relatively hard to falsify because it is composed by two relative statements, “easily adoptable” and “standard”, we feel the need to explain those in more details.
“Easily adoptable” in this context refers to the usage of the new artefact to protect the message content which will not require existing service code to be changed but will require new code to be added to the existing service solution. In addition it is worth mentioning that the authentication and token distribution will be handled outside the service code so it will not require any structural changes but will require additional configuration to be specified.
“Standard” in this context refers to the service code which defines a service, its service contract and where none of the HTTP security features are enabled. Those
“standard” solutions are generally found on the Internet and are often used for
demonstration purposes. Following link from Microsoft demonstrates what we consider to be a standard solution[97].