Codelines

Making web services easily accessible is usually a primary concern when deploying web services but it is important to keep in mind how the service will be used and by whom or what. Hardening deployed web services and providing appropriate level security for the application thereof is a large topic unto itself. However, in this article I’m going to look at what you might secure.

In two previous articles I looked at Information Dissemination with WCF Services and Hosting Options for Windows Communication Foundation Services. In a similar fashion I am going to use the MMO application domain already presented and use it as a basis for discussion in this article.

When discussing web services you will often here a common acronym talked about known as the ABC or Address,  Binding and Contract of web services. This ABC refers to the where (Address), the how (Binding) and the what (Contract).

Securing the Where; i.e. the Address

Consider where the service will reside. Will it be openly accessible on the internet, via a company intranet or only on a local area network. Does it sit behind a firewall, NAT or other interim boundary or does it reside in a DMZ zone? Will it be hosted locally as a windows service, console application or hosted by IIS?

Determing where the service sits and how exposed it is will help with decisions relating to securing the how. For example, depending on the services contract if sitting on and accessible only by the local area network, you might decide securing the binding is not necessary.

Securing the How; i.e. the Binding

Having thought about where the service will reside, further thought can be given to exactly how the service will be consumed and depending on the binding, there are different choices available; Transport level security, message level security and transport level with message level security.

Specifying transport level security leaves it up to the transport layer to implement security. In the case of a https protocol, this might be utilizing transport level encryption and certificate authentication. If you not using transport level security or using a protocol which doesn’t provide any transport level security you can consider message level security; encyption at the message or SOAP level.

There is a good How to: Use Transport Security and Message Credentials on MSDN that discusses specifics in more detail. You might also take a look at securing WCF Service bindings . It discusses username tokens via transport-based security, using default windows credentials,  .NET 2.0 Membership provider model and other advanced WS-* security topics.

Securing the What; i.e. the Contract

When it comes to contract security there are two common approaches; role based security and the notion of security through obscurity (sort of). Role based security allows decorating service operations with defined roles such that different operations in a services contract can only be performed or restricted to certain roles i.e. an administrator, an accountant etc. Role based security is good because it can be built arround the application domain easily. Code-Magazine has a good article on wcf role based authorisation.

The second approach I eluded to; security through obscurity, is less secure (it doesn’t really intend to secure but rather hide operations that aren’t required by particular roles or contracts). Strictly speaking it isn’t a form of security, it’s just a more granular approach at defining contracts such that if you provide access to a contract in the first place, you provide access to it in its entirety (i.e. not only to certain service operations in the case of a contract using role based security).

In the Mmo application domain mocked up in the previous articles I have used this approach to define more granular contracts. For example, an administration service that provides administrative features. For example, creating and deleting accounts. Whilst a general account service is made available to clients whose contract does not support or provide these operations. Similarly the MmoServerRegistry (which keeps track of registered servers) provides two services and conracts; registering/administration and listing/consuming.

Password Encryption

Having looked at security from an ABC perspective (a common way of conceptualising and thinking about wcf web services) the final point of security to mention is that of passwords! Whilst you might provide some obscurity through tightly controlled contracts, operation based authorisation through role based security and transport level, mesage or both, on the binding, it is greatly diminished if you don’t think about encrpyting sensitive credential information where it is stored (often a database or flat file).

When it comes to security, your software is only as secure as the weakest link

WCF Services can be hosted in a number of ways depending on the need and required usage of the service.

Leveraging a Re-Useable WCF Service

Using Visual Studio 2008 you can quickly and easily build flexible WCF services that are hosting environment neutral. That is, build the web service as a library which can be re-used in a variety of hosting environments.

Testing your WCF service

Whilst you can use the svcutil client to test your service by invoking contract operations another approach is to build a simple console application. This same console application, acting as a client, can connect to any server hosted service with a bit of configuration (defined endpoints). The advantage of a console test program over the standard svcutil is that you can do more complex things before and after invoking service operations.

If creating a console application, simply create a new endpoint in your app.config file for each of the endpoints you plan on connecting to; e.g. a local service, windows service and web service.

namespace EnterpriseDotNet.MmoApplication
{
    class MmoAccountApplication
    {
        static void Main(string[] args)
        {
            string heading = "===== Enterprise Dot NET - WCF Service and Client ======";
            Console.WriteLine(heading);
            using (MmoAccountClient client = new MmoAccountClient("BasicHttpBinding_WebService"))
            {
                Console.WriteLine("This service is up and running and can now be accessed...");
                Console.Write("Account from which to perform character selection: ");
                string account = Console.ReadLine();
 
                Console.WriteLine("Retrieving characters...");
                MmoCharacter[] characters = client.GetCharactersForAccount(account);
                Console.WriteLine();
                Console.WriteLine("{0} character(s) found.", characters.Length);
                foreach (MmoCharacter character in characters)
                {
                    Console.WriteLine("\t Character Name: {0}, Level: {1}", character.Name, character.Level);
                }
            }
            Console.WriteLine("Press any key to exit...");
            Console.Read();
        }
    }
}

Sticking with the previous post on WCF this application uses the MMO login service. This app connects to a binding, and retrieves the characters for a given account.

Local hosting

The service is instantiated locally.

Hosting a WCF Service as a windows service

The main difference with a windows service is that typically you will provide an install project for installing the windows service using the installutil that comes with the .NET framework.

You can use installutil.exe path_to_service to install the service and installutil.exe -u path_to_service to uninstall it.

Once the service has been successfully installed, it’s simply a matter of ensuring the service has been started in “Windows Services”.

You can find more information on hosting a WCF Service as a Windows Service here.

Hosting a WCF Service within IIS

This can be achieved in a two step process. Firstly, the service can be hosted in a WCF Web project. Once setup, viewing the service in your browser you can verify that the service is being hosted within the ASP.NET development server. From there it is simply a matter of Setting up a new IIS application pool for the service.

You can find more information on the hosting WCF services in IIS 7 and Windows 2008 here.

Summary

With the use of a WCF service library I have presented three different hosting environments; local hosting, hosting as a windows service and hosting within IIS. WCF Service Libraries offer great flexibility with respect to how they can be invoked by providing a “drop in” deployment approach in a range of hosting environments. How clients are to consume the web service wil often define the best hosting option,

Web services are an integral part of information dissemination amongst heterogenous information sources. Micosoft’s Windows Communication Foundation (WCF) services provide a quick and easy foundation from which to create rich web services. In this post I’m going to look at the main components of the App.config file and the web service contract and implementation.

WCF Endpoints

The three main parts of a WCF endpoint are the address, the binding and the contract. Understanding what an endpoint is made up of helps to understand the function of an endpoint.

Endpoints are used to describe to the client how it may connect to the service and what *endpoint* connections it may do this by. Depending on the binding and contract, the endpoint can be used for different purposes. A wsHttpBinding can be exposed for interacting with the web service and its business logic whilst a mex endpoint with appropriate paramaters can be used to describe the server web service to the client. Connecting to the mex endpoint you can see the WSDL for the web service.

Addresses

The address of the endpoint. When using the address attribute in the endpoint tag of your configuration file, the address is relative. A good example of this is typically the “mex” address which is relative to the base address of the web service. So typically http:///webservice/mex. The address is the location at which the service can be contacted.

Bindings

Bindings define how WCF should provide the underlying communication features of the web service. Their are different types of bindings depending on the purpose. Ad mentioned earlier, their are bindings for meta exchange and different bindings for various transport types (including HTTP and TCP).

Contract

The contract that the endpoint will use in its negotiations with a client. A contract states, what functionality the service will provide to its consumers. This includes how the services methods can be invoked, what parameters they can be invoked with and what types the invocation returns (if any).

namespace EnterpriseDotNet.MmoAccountService
{
    [ServiceContract]
    public interface IMmoAccount
    {
        [OperationContract]
        List<MmoCharacter> GetCharactersForAccount(string account);
    }
 
    [DataContract]
    public class MmoCharacter
    {
        [DataMember]
        public string Name { get; set; }
 
        [DataMember]
        public int Level { get; set; }
    }
}

This is an example of a contract for a ficticous MMO login server. The attributes are used to decorate the interface with meta data.

namespace EnterpriseDotNet.MmoAccountService
{
    public class MmoAccountService : IMmoAccount
    {
        public List<MmoCharacter> GetCharactersForAccount(string account)
        {
            List<MmoCharacter> ret = new List<MmoCharacter>();
 
            using (MmoDataContext context = new MmoDataContext(SQLConnectionString.Settings.Default.SQLServerConnectionString))
            {
                ret = (from c in context.MmoCharacters
                       where c.MmoAccount.Email.Equals(account)
                       select new MmoCharacter
                       {
                           Name = c.Name,
                           Level = c.Level
                       }).ToList();
            }
 
            return ret;
        }
    }
}

This class implements the interface (read service contract) presented earlier. Looking at this service contract it returns a list of characters for a specified account.

Service Behaviours

Service behaviours define how certain aspects of the web service should be configured or behave. When creating a new web service library in Visual Studio 2008, the default behaviour defines two things; serviceMetadata and serviceDebug. The former states that the mex endpoint or meta data exchange will be available via a httpGet and the latter can be used to configure debugging information (exceptions).

There is obviously far more to WCF services than this post touched on. This is an ‘at a glance’ overview of what goes into the definition and configuration of a WCF service.