WCF Services - Security From An ABC Approach
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 ![]()
