At this point, we have learned how to develop a three-layer WCF service with LINQ to Entities. To further enhance our WCF service, in this chapter we will explore the security settings of a WCF service. As big a topic as WCF security is, in this chapter we will only cover the basic concepts, and we will host our HelloWorld WCF service using Basic and Windows Authentication with the HTTPS protocol.
We will cover the following topics in this chapter:
- WCF security components
- WCF transfer security
- WCF Authentication
- Hosting a WCF service with Basic Authentication
- Hosting a WCF service with HTTPS protocol
- Testing the WCF service with Basic Authentication
- Hosting the WCF service with Windows Authentication
- Testing the WCF service with Windows Authentication
- WCF Security Guidance
WCF security spans multiple components in the WCF architecture. The main goal of security in WCF is to provide integrity, confidentiality, authentication, authorization, and auditing for the applications that are built on top of the WCF framework. A good WCF architecture splits these functions into the following pieces:
In this section, we will cover WCF authorization and auditing briefly and in the next section, we will discuss WCF transfer security in details.
Authorization is the process of controlling access and rights to resources, such as services or files. Unlike the WCF service authentication, which is usually handled automatically by the communication framework, for WCF service authorization, you will have to come up with your own strategy and infrastructure. You can choose one of the following to implement authorization for your WCF service:
- Role-based: User is authorized based on his/her role membership. Users belonging to the same role will share the same security privileges within the application.
- Identity-based: Identity Model is an extension of the role-based authorization. Identity Model enables you to manage claims and policies in order to authorize clients. You can verify claims contained within the users' credentials and compare the claims with a set of authorization policies to determine if the user is authorized for an operation.
- Resource-based: Windows access control lists (ACLs) are used for securing individual resources. The caller will be impersonated and the operating system will perform standard access checks, using the original caller's security context when a resource is accessed.
In this book, we will not discuss WCF service authorization any further, as it is fundamentally the same as authorizations of any other types' applications.
WCF applications can log security events (either success, failure, or both), using the auditing feature. The events are written to the Windows system event log and can be examined by using the Event Viewer.
The benefits of WCF auditing include the following:
- Audit security events such as authentication and authorization failures
- Detect attacks which have occurred or which are in progress
- Help debug security-related problems
You can configure the
WCF service security logging through the ServiceSecurityAudit behavior in the service configuration file. You can specify security audit levels for both message authentication and service authorization events.
For example, the following behavior configuration will enable a security audit for all events for both authorization and authentication of a WCF service:
<behavior name = "MySecurityAudit">
<serviceSecurityAudit auditLogLocation = "Default"
serviceAuthorizationAuditLevel = "SuccessOrFailure"
messageAuthenticationAuditLevel = "SuccessOrFailure" />
</behavior>In the rest of this chapter, we will focus on the transfer security part of WCF services. We will discuss WCF transport-level and message-level security, transfer security modes supported by various bindings, and WCF authentications.
WCF transfer security is also referred to as security mode. There are two transfer security levels for WCF services—transport level and message level. You can also mix these two levels to create a mixed-level security mode.
The WCF security modes that are available are as follows:
Not every WCF binding supports every security mode. For example, basicHttpBinding supports transport, message, or mixed security modes, but not both, while netNamedPipeBinding only supports transport-level security (or none). The following table lists the
most common bindings and their supported security modes:
|
Binding name |
None |
Transport |
Message |
Mixed |
Both |
|---|---|---|---|---|---|
|
√(Default) |
√ |
√ |
√ |
X | |
|
√ |
√(Default) |
√ |
√ |
X | |
|
√ |
√(Default) |
√ |
√ |
X | |
|
√ |
√(Default) |
X |
X |
X | |
|
√ |
√ |
√(Default) |
√ |
X | |
|
√ |
X |
√(Default) |
X |
X | |
|
√ |
X |
√(Default) |
X |
X | |
|
√ |
√(Default) |
√ |
X |
√ |
WCF transport security is applied at the transport level on the byte stream below the message layer. In this case, a message does not have a security header and it does not carry any user authentication data. Transport security mode only provides point-to-point security between the two endpoints and it is the least flexible in terms of WS-Security usage because it is highly dependent on the transport layer. However, the transport security mode is the fastest in terms of performance, and it gives the best interoperability with client applications.
The most common approach for transport security mode is to combine it with Secure Sockets Layer (SSL) or HTTPS to encrypt and sign the contents of all packets. We will secure a WCF service with transport security and SSL in later sections of this chapter.
WCF message security is applied on the message level. With message security, the user credentials and claims are encapsulated in every message. The message security mode provides end-to-end security and it provides a high flexibility from an authentication perspective. Since messages are directly encrypted and signed, having intermediaries does not break the security. You can use any type of authentication credential you want, largely independent of the transport layer as long as both client and server agree.
WCF mixed security gives you the best of both transport security and message security. In this case, WCF transport security ensures the integrity and confidentiality of the messages, while WCF message security encapsulates the user credentials and claims in every message. The WCF mixed security mode allows you to use a variety of user credentials that are not possible when using strict transport security mechanisms, while leveraging transport security's performance.
When WCF transport security and WCF message security are combined, the user credentials and claims are transferred at both the transport layer and the message level. Similarly, message protection is provided at both the transport layer and the message level. Note that this is not a common scenario, and the Microsoft Message Queuing (MSMQ) binding is the only binding that supports this mode.
The WCF authentication options depend on the transfer security mode being used. For this reason, the authentication choices are partly determined by the transfer security mode. The following are the available authentication options for transport security mode:
- None: When using the None option, the callers are not authenticated at all.
- Basic: The Basic option is available with the HTTP protocol only. The client is authenticated by using the username and password against the Microsoft Active Directory service. Note the username and password are transported by using a Base64 encoded string, which is very similar to a clear string and therefore not the most secure option.
- NTLM: The NTLM option is also available with the HTTP protocol only. The client is authenticated by using a challenge-response scheme against Windows accounts. NTLM Authentication is well suited for a workgroup environment and is more secure than Basic Authentication.
- Windows: When using the Windows option, the WCF service uses Kerberos Authentication when in a domain, or NTLM Authentication when deployed in a workgroup environment. This option uses a Windows token presented by the caller to authenticate against the Active Directory. This is the most secure option compared to Basic or NTLM Authentication.
- Certificate: When using the Certificate option, the caller presents an X.509 client certificate that the WCF service validates by trusting the certificate (peer trust) or trusting the issuer of the certificate (chain trust). This option should be considered only when Windows Authentication is not possible, as in the case of business-to-business (B2B) scenarios.
For WCF services using the message security mode, authentication choices are different from the services using the transport security mode. The following are the available authentication options for the message security mode:
- None: When using the None option, the callers are not authenticated at all.
- Windows: When using the Windows option, the WCF service uses Kerberos Authentication when in a domain or NTLM Authentication when deployed in a workgroup environment. The Windows option uses the Windows token presented by the caller to authenticate against the Active Directory.
- Username: When using the Username option, the caller provides a username and password to the service. The service can then authenticate the caller against Windows credentials or use a membership provider. This option should be considered only when Windows Authentication is not possible.
- Certificate: When using the Certificate option, the caller presents an X.509 client certificate. The WCF service looks up the certificate information on the host side and validates it (peer trust), or trusts the issuer of the client certificate (chain trust). This option should be considered only when Windows Authentication is not possible.
- Issue Token: When using the Issue Token option, the client and service depend on Secure Token Service (STS) to issue tokens that the client and service trust.