What Is Security?

Security is concerned with protecting users running client applications, services, and the messages that pass between them. Security encompasses a range of issues. The most common aspects of security that most developers are familiar with include user authentication, where a user attempts to prove their identity, and authorization, where a service decides which resources a user can access based on their identity. However, in a distributed environment, security has many other facets. These include:

• Maintaining confidentiality of communications between a client application and a service. It is possible for applications to eavesdrop on the data being transmitted across the network. For example, take a look at the number of software and hardware network analyzers available–many administrators use them for tracking connectivity and bandwidth problems in a network, but an unscrupulous user could also track the packets passing over the network for malicious purposes. The information in these packets could include private financial data or confidential personal information that should not be common knowledge even to other members of the same organization. Typically, you achieve confidentiality by encrypting messages.

• Preventing tampering or corruption of messages. In an environment where message confidentiality is assured, it is still possible for a malicious user to intercept messages and corrupt them before sending them to their final destination. You can use techniques such as message hashing to generate a digital signature for the file, which a service can use to help detect corrupt or modified messages.

• Ensuring verifiable delivery of messages. Even if a malicious user cannot decipher intercepted messages, the possibility of interception means that messages could either be diverted and not delivered at all or delivered repeatedly (known as a “replay attack”). Several schemes are available that can help detect replay attacks, including using a timestamp within a message (if the timestamp is outside reasonable limits when the service receives the message, it can discard it) and assigning unique identifiers to messages (if the service receives two messages with the same identifier, then it knows that there is a problem!). Similarly, using a reliable message protocol can help to ensure that messages are either delivered to the destination within a reasonable time or that the sender will be alerted if they are not. You will learn more about reliable messaging in Chapter 9, “Implementing Reliable Sessions.”

• Preventing impersonation of services. Although not so common inside an enterprise as it is when using the Internet, it is possible for one service to impersonate another to obtain confidential data from a user. This phenomenon is sometimes known as “spoofing.” The user running the client application thinks they are communicating with the real service but are actually sending their details and other information to an entirely different service that happens to respond in a similar manner. This means that it can be as important for a client application to authenticate the service and verify that it is genuine as it is for a service to authenticate the user running the client application. You will look at how you can implement this form of two-way authentication by using certificates in Chapter 5.

It is worth remembering that there is no such thing as absolute security. Hackers and fraudsters can invariably devise new and interesting ways to intercept, compromise, or otherwise disrupt the message flow. The important point is to be aware of the threats and have a plan for introducing countermeasures that can reduce their effects. Fortunately, WCF provides a highly extensible model that can adapt and evolve to meet many current security issues and (hopefully) counter new threats as they appear. The WCF implementation of security is also relatively unobtrusive. By careful design and configuration, you can separate many of the security-related aspects of a client application and service from the business logic, enabling you to modify or extend the security of your system without requiring that you rewrite large chunks of code.

Authentication and Authorization in a Windows Environment

To authenticate a user, a service must provide a means of enabling a user to identify herself and then prove that identity. Inside a single organization, it is common to maintain a single database of users and their means of identification. In a Windows environment, this typically means using Active Directory. In a single organization, it is not unreasonable to expect that all services and client applications have access to the same Active Directory database, and this database defines the security domain for the system. A service can be configured to use information held in the Active Directory database to authenticate users. When the user runs an application that accesses the service, the application can prompt the user for their username and password and transmit this information to the service. The service can query Active Directory to verify that the username is valid and the password is correct.

Note 

Many of the discussions on this chapter that refer to Active Directory also apply to Windows computers that are not actually part of a domain but that maintain their own local users and groups database. The exercises in this chapter have been tested on a stand-alone computer running Microsoft Windows XP and Windows Vista.

In a Windows domain, a service can also identify users by using the Kerberos protocol, and a WCF client application can verify the identity of a service by using the same protocol. However, Kerberos is only available if you have access to a Windows Server domain controller. This chapter does not describe how to configure a WCF service and client application to perform Kerberos authentication. For a brief summary of how Kerberos authentication works, see the Kerberos V5 Authentication page on the Microsoft Web site at http://technet2.microsoft.com/WindowsServer/f/?en/library/1033.mspx.

This approach works regardless of where the user is actually running the client application; it could be executing on a computer in the user’s bedroom connecting to the service across an Intranet link, for example. However, a user located in the office might already be logged on to an organization’s security domain, so prompting them for the username and password again becomes cumbersome (why should they need to keep on logging in?). Fortunately, the Windows operating system provides support for this very common scenario. When a user successfully logs in to a security domain, the details of the user’s credentials are cached in the user’s login process. When the user runs an application that requires authentication with a service, Windows can provide these details to the application, which can then forward them to the service. This mechanism is known as Windows Integrated Security.

Note 

In a very large organization, the security domain might span several Active Directory databases managed independently by administrators in different parts of the organization. It is possible to configure trust relationships between these separate domains, effectively presenting them as a single security domain.

After a service has verified the identity of the user running the client application, it must then determine whether the user has the appropriate authority to invoke the specified operations. Typically, administrators assign users to roles, and the service developer can indicate which roles are allowed to access which operations. WCF can utilize .NET Framework declarative security to associate roles with operations. WCF can use a role provider to determine to which roles a user belongs. The .NET Framework provides three role providers that you can use for storing role information. These role providers are:

• Windows Token Role Provider, which uses roles based on Active Directory groups.

• SQL Role Provider, which uses roles stored in a SQL Server database.

• Authorization Store Role Provider, which uses roles defined by using the Microsoft Authorization Manager tool. This tool enables you to store role information in Active Directory or in XML files.

More Info 

For detailed information on using Microsoft Authorization Manager to define and implement roles, see the Authorization Manager page on the Microsoft Web site at http://technet2.microsoft.com/WindowsServer/en/library/1033.mspx?mfr=true.

In this chapter, you will use the Windows Token Role Provider. This provider is ideal for use inside an enterprise that uses Windows Integrated Security for authentication. In Chapter 5, you will see how to use the SQL Role Provider as this is more suited to Internet-based services.

Transport and Message Level Security

User identity information has to be transported from a client application to a service. This information is critical, and so it should be transmitted in as secure a manner as possible. This normally means encrypting these details. Additionally, after the user has been authenticated, the contents of messages passing between the client application and service might also require some form of encryption, depending on the sensitivity of the information in these messages. There are many ways that client applications and services can achieve this aim, but the important point is that the client applications and the service must agree on the mechanism that they use, and they must be able to decrypt messages sent by the other. Various standardization efforts have led to the use of public/private key cryptography being used to this effect.

More Info 

For a good introduction to public key cryptography, visit the Understanding Public Key Cryptography page on the Microsoft Web site at http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3MsgSecGuide/.mspx?mfr=true.

When building Web services, you can perform authentication and encryption at two points when sending and receiving messages: at the transport level and at the message level.

Transport Level Security

Transport level authentication is typically implemented at the operating system level before the application or service receiving the message even knows that there is a message to receive! A service can specify the type of credentials it requires, but it is the operating system’s responsibility to ensure that the correct credentials are provided and to validate them.

Many communications protocols can encrypt and decrypt data as it is sent and received. The most common example of such a protocol is HTTPS, which uses a technology called the Secure Sockets Layer (SSL) to encrypt and decrypt data by using keys provided in certificates. When a client application connects to a service by using the HTTPS protocol, the underlying transport infrastructure for the client application and service can negotiate over the degree of encryption to perform and exchange a certificate containing keys that they can use to encrypt and decrypt messages. Because all of this happens at the transport level, it is transparent to the client application and service; all they have to do is specify that they will communicate using the HTTPS protocol. However, an administrator has to install and configure the appropriate certificates for the service host application. Unsurprisingly, you can also use transport level security with the TCP protocol (SSL is itself based on TCP). Named pipes also support transport level security.

More Info 

In this chapter, you will configure HTTPS for use with a self-hosted WCF service. If you are hosting a WCF service in IIS, the configuration process is a little different. You will learn more about configuring HTTPS with IIS in Chapter 5.

Message Level Security

Authentication at the message level is the responsibility of the service. The credentials of the user are included in messages sent to the service, and the service has to verify that they are valid. Additionally, message level privacy and integrity is also the responsibility of the client application and service–they encrypt and decrypt messages themselves using an agreed encryption algorithm and a negotiated set of encryption keys. Standards such as the WS-Security specification from OASIS describe the message level security schemes that many Web services implementations have adopted, and by following the recommendations of WS-Security you can help to ensure the interoperability of your client applications and services with those developed by using technologies other than WCF.

Transport level security has the advantage over message level security that it can often rely on hardware support and can be very efficient–encrypting and decrypting data can be a resource-intensive process, so anything that improves performance is very welcome. Additionally, transport level authentication checks are enforced before the client application actually starts sending application level messages, so performing authentication at this level detects authentication failures more quickly and with less network overhead. The primary disadvantage of transport level security is that it operates on a point-to-point basis; by the time the service receives a message, it has already been decrypted by the underlying transport mechanism. In a situation where a service should simply forward a message on to another service rather than process it, it has full access to the message contents. The service could modify the message or extract confidential information before forwarding it. Using message level encryption can help to mitigate this problem. Message level security provides end-to-end encryption. A client application and the service acting as the final destination can agree on an encryption key and an encryption algorithm to use for messages. When a message arrives at the intermediate service, it is still encrypted. If the intermediate service does not have access to the encryption key or has no knowledge of the selected encryption algorithm, it cannot easily decrypt the message.

Implementing message level security sounds like it could add quite a lot of work to the development effort required for building a service. However, WCF greatly simplifies matters and reduces the development effort required by incorporating much of the code required as part of the standard bindings you can specify when configuring an endpoint for a service. All you need to do is set the properties of your selected binding appropriately (you will see several examples throughout this chapter).