Hosting

A web service in WCF can be hosted in two different ways. Either it can create a socket and listen for an incoming request from a client, or it can be hosted on a server.

A web service hosted on the Microsoft Internet Information Server (IIS) can benefit from all the built in functionality for handling web applications. For instance IIS has extensive use of security, logging and check on health of the running service. In a large environment with many web applications this will probably be the best solution because the configuration can be managed in an easy way. On the downside an IIS has to be installed on the host machine and of course be maintained.

Self hosting enables the service to run in almost any managed code environment like a consol application or a form application. Self hosting is great for testing or custom applications. To have a service run as a self hosting system will take longer time to develop than a server hosted service. This is because of all the code needed in order to host the service, thread pool, security and service logging. For this thesis it is hosted in an IIS, and self hosting has been used for the tests conducted in case study 3.

3.3.8 Security

Security is an integrated part of WCF and web services. Without security it would be hard to use web services unless you did not care who could read you messages, and who you were communicating to. In a business operation this is usually not the case. At the same time security must be easy to use ensuring that the programmers can concentrate on what they are paid for; to design business related programs.

WCF provides a number of out-of-the-box security features that can be used.

Actually, when setting up a standard wsHttpBinding, security is turned on by default.

WsHttpBinding and NetTcpBinding both uses message level security by default according to WS-Security and WS-Secure Conversation, ensuring CIA¹⁶ for the message.

Credentials is by default set to windows credentials, that identifies the user logged in using Kerberos or NTLM, however, other methods can be used as well. A service can

have as may connections as needed; each schema simply needs an endpoint exposing it to the world. [KB2006]

The basicHttpBinding do not support the described security features, but that does not mean that the binding can not be secured. In order to have CIA for this binding, it must be deployed over the HTTPS protocol. If the service is hosted under IIS all that is needed is to turn on SSL support for the virtual directory holding the service, and making sure that transport level security is used. Using SSL is a transport based security, and as such it is restricted to an end-to-end scenario instead of a point-to-point security. This makes it hard to reuse the security channel for other transport protocols like TCP, SMTP or MSMQ. At the same time HTTPS do not supply a way to ensure non-repudiation, for a message going through several channels. (Data tampering)

By default an anonymous client is used. This will not tell the server who the client is but it will ensure the transportation is secure through the use of the web servers’

certificate. This is the most used pattern for secure web communication today.

WCF provides many security features, and configurations of these securities.

These security properties can be changed through the configuration file.

3.3.8.1 Message and transport level security.

Securing the messages for a web service, there exist two major methods.

Transport level and Message level .Transport level security uses the underling network protocols for the security. One of the transport level protocols is the well known https protocol. The web service constructs a SOAP message and passes it to the network.

Before the message is sent to the network, it is encrypted by the known encryption key.

SSL uses a mixture of public and private key encryption, which makes it fast and still secure. Figure 17 shows transport level security.

Figure 17 Transport security

SOAP message

SOAP SOAP

The entire SOAP message is encrypted in this way. At the receiving end the message are decrypted and delivered as the original SOAP message. The transport pipe the message goes through protects the message whilst inside the pipe. In a scenario where the message is to be re-routed it has to be opened and re-send on the intermediate base.

This of course leaves the message exposed at that intermediate point, making it readable.

In message level security only parts of the message would be encrypted. This would only be the payload. The information about where the message is going to be sent to is completely readable to anyone, but the data is kept secret. In that case the message could be passed freely around the network without any dangers. Only when the message arrives at its destination could it be read. This opens for the possibility of sending the message through several channels. The final receiver of the message is the only one who has the right key to open and understand the message and thus has exclusive access.

Message level security therefore reduces the exposure time for a message. Transport level is restricted to certain protocols, while message level can be distributed with any available protocol. Message level security is sometimes referred to as end-to-end security.

Message level security is a newer way to handle the problem, and therefore it support more features for web services security. It is better integrated with the standards for web services, but it comes at a price. The performance for transport level security still surpasses message level security. If performance is an issue, transport level security is then still to prefer. Whenever possible, message level makes for a much better approach concerning the web service standard.

Figure 18 Message level security

SOAP message

SOAP SOAP

3.4 Summary

Different technologies and techniques have been explained throughout this chapter.

Especially the new developments in web services and SOA have been introduced and the main advantages of making use of these technologies have been clarified. SOA is to be used in the prototype because of the great cross platform and language inter-communicable properties.

The final product will make use of both WCF and standard web services through a modularized interface. However the main focus will be on WCF since it is a new and enhanced architecture for web services. Because of the way that WCF support WS-I standards it maintains the possibility of incorporating new standards and features in a seamless and easy way.

In the next chapter, a case study for the prototype will be presented where the requirements and the technologies described in this and the previous chapters will be tested.

Chapter 4

IMPLEMENTATION AND CASE STUDIES

The purpose of this chapter is to try out some of the different scenarios that the system is supposed to work under. The system must be able to work under very different configurations, so some of the case studies are of a more general type. The overall design of the system has been built in order to have the same basic design for all the challenges, and then make minor changes in order to add or remove functionalities to the system.

Before studying each case, the setup, overall architecture and the internal workings of the server system will be described in the following section.