Fast Track: A Guide for Getting Started and Applying the Guidance

Summary

This “fast track” chapter highlights the basic approach taken by this guide to help you design and develop WCF applications with security in mind. Use this chapter to understand the basic approach, security engineering activities, key scenarios, the security frame, and best practices for the development of secure WCF applications with security.

Goal and Scope

This guide shows you how to design and build secure Web services with WCF.

It includes:

• End-to-end application scenarios
• Guidelines
• Step-by-step "How-to" articles

The Approach

The keys to building secure services include:

• Identify your security objectives. This includes identifying your particular security requirements.
• Know your threats. Know which threats are relevant for your scenarios and context. Threat modeling is an effective technique for helping you identify relevant threats and vulnerabilities. Your objectives will help you prioritize your threats and vulnerabilities. Based on the threat model, developers address vulnerabilities, and testers verify that the developers closed the issues.
• Apply proven principles, patterns, and practices. By using proven principles, patterns, and practices, you can eliminate classes of security problems. You can also leverage lessons learned. Patterns are effectively reusable solutions and typically encapsulate underlying principles. While principles, patterns, and practices are a good starting point, you should never blindly adopt them—you need to evaluate whether they make sense for your specific scenario.
• Apply effective security engineering throughout the application life cycle. It is important to consider security throughout your application life cycle. You should start by setting your security objectives. Threat modeling will help you shape your design and make key trade-offs. Security design, code, and deployment inspections, along with testing, will improve your overall security posture.

patterns & practices Security Engineering

The Microsoft patterns & practices Security Engineering approach includes specific security-related activities that help you meet your application security objectives.

Figure 1
Security Engineering Activities

Summary of Key Security Engineering Activities

The Microsoft patterns & practices Security Engineering approach extends these proven core activities to create security-specific activities. These activities include:

• Security objectives. Setting objectives helps you scope and prioritize your work by setting boundaries and constraints. Setting security objectives helps you identify where to start, how to proceed, and when you are done.
• Threat modeling. Threat modeling is an engineering technique that can help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application. You can use threat modeling to shape your application’s design, meet your company’s security objectives, and reduce risk.
• Security design guidelines. Creating design guidelines is a common practice at the start of an application project, in order to guide development and share knowledge across the team. Effective design guidelines for security organize security principles, practices, and patterns by actionable categories.
• Security design inspection. Security design inspections are an effective way to identify problems in your application design. By using pattern-based categories and a question-driven approach, you simplify evaluating your design against root-cause security issues.
• Security code inspection. Many security defects are found during code reviews. Analyzing code for security defects includes knowing what to look for and how to look for it. Security code inspections optimize inspecting code for common security issues.
• Security testing. Use a risk-based approach and use the output from the threat modeling activity to help establish the scope of your testing activities and define your test plans.
• Security deployment inspection. When you deploy your application during your build process or staging process, you have an opportunity to evaluate your application’s run-time characteristics in the context of your infrastructure. Deployment reviews for security focus on evaluating your security design and the configuration of your application, host, and network.

For more information on security engineering, see patterns & practices Security Engineering Explained.

End-to-End Scenarios

Intranet

The following figure is an example of a common WCF intranet scenario. Note the use of the TCP protocol. WCF is hosted by the Windows service, and Windows authentication is used to authenticate users inside the Windows domain.

Figure 2
A Common WCF Intranet Scenario

Internet

The following figure is an example of a common WCF Internet scenario. Note the use of the HTTP protocol. WCF is hosted in Internet Information Services (IIS), and Username authentication is used to authenticate users.

Figure 3
A Common WCF Internet Scenario

Web Services Security Frame

The following key security concepts provide a frame for thinking about security when designing and architecting services. This helps you turn core security features such as authentication, authorization, auditing, confidentiality, integrity, and availability into action.

Category	Description
Auditing and Logging	Auditing and logging refers to how security-related events are recorded, monitored, and audited.
Authentication	Authentication is the process in which an entity proves the identity of another entity, typically through credentials, such as a username and password.
Authorization	Authorization is how your service provides access controls for resources and operations.
Configuration Management	Configuration management refers to how your service handles database connections, administration, and other configuration settings.
Exception Management	Exception management refers to how you handle exceptions within your application, including fault contracts.
Impersonation/Delegation	Impersonation and delegation refers to how your service impersonates users and passes identity information downstream for authorization purposes.
Message Encryption	Message encryption refers to protecting a message by converting the contents to cipher text by using cryptographic methods.
Message Replay Detection	Message replay detection refers to identifying and rejecting messages that are resubmitted.
Message Signing	Message signing refers to signing a message with a digital signature using cryptographic methods, to confirm the source of the message and detect if the contents have been tampered with (i.e., authentication and integrity of the message).
Message Validation	Message validation refers to how you verify the message payload against a schema, as well as message size, content, and character sets. This includes how your service filters, scrubs, and rejects input and output before additional processing. Input and output includes input from clients consuming the service as well as file-system input, in addition to input from network resources, such as databases. Output typically includes the return values from your service or disk/database writes, among others.
Sensitive Data	Sensitive data is user and application data whose integrity and confidentiality need to be protected. This includes how you protect sensitive data from being stolen from memory, from configuration files, or when transmitted over the network.
Session Management	A session refers to a series of related interactions between a client and your service.

Threats and Attacks to Your Web Services

The following table highlights some of the common threats and attacks against Web services.

Category	Description
Auditing and Logging	Tampering with log files Ineffectual or nonexistent audit processes
Authentication	Network eavesdropping Brute force attacks Dictionary attacks Cookie replay attacks Credential theft
Authorization	Elevation of privilege Disclosure of confidential data Data tampering Luring attacks
Configuration Management	Unauthorized access to administration interfaces Unauthorized access to configuration stores Retrieval of clear text Configuration secrets No individual accountability
Exception Management	System or application details are revealed Denial of service (DoS)
Impersonation/Delegation	Elevation of privilege
Message Encryption	Information disclosure
Message Replay Detection	Horizontal and vertical privilege escalation
Message Signing	Data tampering
Message Validation	Buffer overflows Cross-site scripting SQL injection Canonicalization attacks
Sensitive Data	Accessing of sensitive data in storage Network eavesdropping Information disclosure
Session Management	Session hijacking Session replay Man-in-the-middle attacks

Guidelines for Your Web Services

The following table summarizes effective guidelines to improve the security of your Web services.

Category	Description
Auditing and Logging	Identify malign or malicious behavior. Know your baseline (e.g., what does good traffic look like?). Instrument to expose behavior that can be watched. (The big mistake here is typically that application instrumentation is completely missing. Create a process to watch the logs and an escalation path for significant issues.
Authentication	Use strong password policies. Do not store credentials on the client side. Do not store credentials in clear text on the server side. Encrypt communication channels to secure authentication tokens. Use secure protocols such as Secure HTTP (HTTPS) to secure authentication tokens.
Authorization	Use least-privileged accounts. Consider granularity of access. Enforce separation of privileges. Use role-based access control.
Configuration Management	Use least-privileged service accounts. Do not store credentials in plaintext format. Use strong authentication and authorization on administrative interfaces. Do not use the Local Security Authority (LSA). Avoid storing sensitive information in the Web space or in configuration files, especially in clear text.
Exception Management	Use structured exception handling (try-catch-finally). Only catch and wrap exceptions if the operation adds value/information. Do not reveal sensitive system or application information. Do not log private data (passwords, etc.). Use the finally block to perform cleanup. Be cognizant of exception filters.
Impersonation/Delegation	Use constrained delegation. Do not hard-code credentials in your code and preferably not in the configuration files. Use IIS application domains or Windows service accounts for the host. Encrypt credentials; if you do, put them in configuration files.
Message Encryption	Use strong algorithms with appropriate cipher modes, key management, key length, etc.
Message Replay Detection	Enable replay detection within WCF. Use nonces and unique tokens to detect replay or unauthorized requests.
Message Signing	Use strong algorithms with appropriate padding modes, key management, key length, etc. Avoid use of self-signed certificates.
Message Validation	Use schema validation. Offload schema validation to an XML accelerator if possible. Use parameter validation.
Sensitive Data	Do not store secrets in software. Enforce separation of privileges. Encrypt sensitive data over the network. Secure the channel. Avoid key management. Cycle your keys.
Session Management	Partition services by anonymous, identified, and authenticated users. Reduce session timeouts. Avoid storing sensitive data in session stores. Secure the channel to the session store. Authenticate and authorize access to the session store.

Web Services Security Patterns

The following table summarizes Web services security patterns and provides links to more information.

Pattern	Description	Reference
Authentication
Direct Authentication	The Web service acts as an authentication service to validate credentials from the client. The credentials, which include proof-of-possession that is based on shared secrets, are verified against an identity store.	https://msdn.microsoft.com/en-us/library/aa480566.aspx
Brokered Authentication	The Web service validates the credentials presented by the client, without the need for a direct relationship between the two parties. An authentication broker that both parties trust independently issues a security token to the client. The client can then present credentials, including the security token, to the Web service.	https://msdn.microsoft.com/en-us/library/aa480560.aspx
Brokered Authentication: Kerberos	Use the Kerberos protocol to broker authentication between clients and Web services.	https://msdn.microsoft.com/en-us/library/aa480562.aspx
Brokered Authentication: X509 PKI	Use brokered authentication with X.509 certificates issued by a certificate authority (CA) in a public key infrastructure (PKI) in order to verify the credentials presented by the requesting application.	https://msdn.microsoft.com/en-us/library/aa480565.aspx
Brokered Authentication: Security Token Service (STS)	Use brokered authentication with a security token issued by an STS. The STS is trusted by both the client and the Web service to provide interoperable security tokens.	https://msdn.microsoft.com/en-us/library/aa480563.aspx
Authorization
Protocol Transition with Constrained Delegation	Use the Kerberos protocol extensions in Windows Server. The extensions require the user ID but not the password. You still need to establish trust between the client application and the Web service; however, the application is not required to store or send passwords.	https://msdn.microsoft.com/en-us/library/aa480585.aspx
Trusted Subsystem	The Web service acts as a trusted subsystem to access additional resources. It uses its own credentials instead of the user’s credentials to access the resource.	https://msdn.microsoft.com/en-us/library/aa480587.aspx
Exception Management
Exception Shielding	Sanitize unsafe exceptions by replacing them with exceptions that are safe by design. Return only those exceptions to the client that have been sanitized or exceptions that are safe by design. Exceptions that are safe by design do not contain sensitive information in the exception message, and they do not contain a detailed stack trace, either of which might reveal sensitive information about the Web service’s inner workings.	https://msdn.microsoft.com/en-us/library/aa480591.aspx
Message Encryption
Data Confidentiality	Use encryption to protect sensitive data that is contained in a message. Unencrypted data, which is known as plaintext, is converted to encrypted data, which is known as cipher text. Data is encrypted with an algorithm and a cryptographic key. Cipher text is then converted back to plaintext at its destination.	https://msdn.microsoft.com/en-us/library/aa480570.aspx
Message Replay Detection
Message Replay Detection	Cache an identifier for incoming messages, and use message replay detection to identify and reject messages that match an entry in the replay detection cache.	https://msdn.microsoft.com/en-us/library/aa480598.aspx
Message Signing
Data Origin Authentication	Use data origin authentication, which enables the recipient to verify that messages have not been tampered with in transit (data integrity) and that they originate from the expected sender (authenticity).	https://msdn.microsoft.com/en-us/library/aa480571.aspx
Message Validation
Message Validator	The message validation logic enforces a well-defined policy that specifies which parts of a request message are required for the service to successfully process it. It validates the XML message payloads against an XML schema (XSD) to ensure that they are well-formed and consistent with what the service expects to process. The validation logic also measures the messages against certain criteria by examining the message size, the message content, and the character sets that are used. Any message that does not meet the criteria is rejected.	https://msdn.microsoft.com/en-us/library/aa480600.aspx
Deployment
Perimeter Service Router	Design a Web service intermediary that acts as a perimeter service router. The perimeter service router provides an external interface on the perimeter network for internal Web services. It accepts messages from external applications and routes them to the appropriate Web service on the private network.	https://msdn.microsoft.com/en-us/library/aa480606.aspx

Bindings in WCF

The following table summarizes common bindings in WCF.

Binding	Description
basicHttpBinding	Configures and exposes endpoints that are able to communicate with ASP.NET Web Services (ASMX)–based Web services and clients and other services that conform to the WS-I Basic Profile 1.1 specification. By default, it has security disabled.
wsHttpBinding	Defines a secure, reliable, interoperable binding suitable for non-duplex service contracts. The binding implements the following specifications: WS-Reliable Messaging for reliability, and WS-Security for message security and authentication. The transport is HTTP, and message encoding is text/XML encoding. By default, it provides message security with Windows authentication.
ws2007HttpBinding	Defines a secure, reliable, interoperable binding suitable for non-duplex service contracts. The binding implements the following specifications: WS-Reliable Messaging for reliability, and WS-Security for message security and authentication. The transport is HTTP, and message encoding is text/XML encoding. The ws2007HttpBinding provides binding similar to wsHttpBinding but uses the standard for OASIS (Organization for the Advancement of Structured Information Standards). By default, it provides message security with Windows authentication.
netTcpBinding	Specifies a secure, reliable, optimized binding suitable for cross-machine communication. By default, it generates a run-time communication stack with transport security and Windows authentication as default security settings. It uses TCP protocol for message delivery, and binary message encoding.
netNamedPipeBinding	Defines a binding that is secure, reliable, and optimized for cross-process communication on the same machine. By default, it generates a run-time communication stack with WS-ReliableMessaging for reliability, transport security for transfer security, named pipes for message delivery, and binary message encoding. It is not secured by default.
netMsmqBinding	Defines a queued binding suitable for cross-machine communication.
wsFederationHttpBinding	Defines a binding that supports federated security. It helps implement federation, which is the ability to flow and share identities across multiple enterprises or trust domains for authentication and authorization. WCF implements federation over message and mixed-mode security but not over transport security. Services configured with this binding must use the HTTP protocol as transport.
ws2007FederationHttpBinding	Defines a binding that derives from wsFederationHttpBinding and supports federated security. It helps implement federation, which is the ability to flow and share identities across multiple enterprises or trust domains for authentication and authorization. WCF implements federation over message and mixed-mode security but not over transport security. Services configured with this binding must use the HTTP protocol as transport. The ws2007FederationHttpBinding provides binding similar to ws2007FederationHttpBinding but uses the OASIS standard.
wsDualHttpBinding	Defines a secure, reliable, and interoperable binding that is suitable for duplex service contracts or communication through Simple Object Access Protocol (SOAP) intermediaries.
customBinding	Allows you to create a custom binding with full control over the message stack.

Transport Security

When using transport security, the user credentials and claims are passed by using the transport layer. In other words, user credentials are transport-dependent, which allows fewer authentications options compared to message security. Each transport protocol (TCP, IPC, MSMQ, or HTTP) has its own mechanism for passing credentials and handling message protection. The most common approach is to use Secure Sockets Layer (SSL) for encrypting and signing the contents of the packets sent over HTTPS.

Transport security is used to provide point-to-point security between the two endpoints (service and client). If there are intermediary systems between client and the service, each intermediate point must forward the message over a new SSL connection.

Figure 4
Transport Security

Use transport security for the following scenarios:

• You are sending a message directly from your application to a WCF service, and the message will not be routed through intermediate systems.
• You have both the service and the client in an intranet.

Using transport security offers the following advantages:

• It provides interoperability, meaning that communicating parties do not need to understand the WS-Security specifications.
• It may result in better performance.
• Hardware accelerators can be used to further improve performance.

Using transport security has the following disadvantages:

• Security is applied on a point-to-point basis, with no provision for multiple hops or routing through intermediate application nodes.
• It supports a limited set of credentials and claims compared to message security.
• It is transport-dependent upon the underlying platform, transport mechanism, and security service provider, such as NTLM or Kerberos.

Message Security

When using message security, the user credentials and claims are encapsulated in every message by using the WS-Security specification to secure messages. This option gives the most flexibility from an authentication perspective. You can use any type of security credentials you want, largely independent of transport, as long as both the client and service agree.

Figure 5
Message Security

Use message security for the following scenarios:

• You are sending a message to a WCF service, and the message is likely to be forwarded to other WCF services or may be routed through intermediate systems.
• Your WCF clients are accessing the WCF service over the Internet.

Using message security offers following advantages:

• It provides end-to-end security; because message security directly encrypts and signs the message, having intermediaries does not break the security.
• It allows partial or selective message encryption and signing, thus improving overall application performance.
• Message security is transport-independent and thus can be used with any transport protocol.
• It supports a wide set of credentials and claims, including issue tokens, which enable federated security.

Using message security has following disadvantages:

• This option may reduce performance compared to transport security because each individual message is encrypted and signed.
• It does not support interoperability with older ASMX clients since it requires both the client and service to support WS-Security specifications.

Authentication

Transport Security

The follow authentication options are available when using transport security mode:

• None. When using this option, the WCF service does not authenticate the callers. This is not the recommended option from a security perspective—avoid using this option wherever possible.
• Basic. This option is available with the HTTP protocol only. The client is authenticated by using the username and password against Active Directory. The client credentials are transported by using Base64 encode string, which is literally like clear string and therefore is not the most secure option. The service is authenticated by the SSL certificate used for secure communication.
• NTLM. This option is available with the HTTP protocol only. The client is authenticated by using a challenge-response scheme against Windows accounts. The NTLM option is well suited for a workgroup environment. NTLM authentication is more secure than either Digest or Basic authentication. The service is authenticated by using the Windows credentials of the process identity, or by using an SSL certificate if you are using the HTTP protocol.
• Windows. The Windows option tells the WCF service to use Kerberos when in a domain or NTLM when deployed in a workgroup environment. This option uses a Windows token presented by the caller to authenticate against Active Directory. This is the most secure option compared to Basic, Digest, or NTLM authentication. The service is authenticated by using the Windows credentials of the process identity or an SSL certificate if you are using the HTTP protocol.
• Certificate. When using this option, the caller presents an X.509 client certificate that the WCF service either validates with peer trust or trusts based on the issuer of the certificate. This option should be used when Windows authentication is not possible, as in the case of business-to-business (B2B) scenarios. The service is authenticated with the service certificate or by using an SSL certificate if you are using the HTTP protocol.

Message Security

The follow authentication options are available when using message security mode:

• None. When using this option, the WCF service does not authenticate the callers. This is not the recommended option from a security perspective—avoid using this option wherever possible.
• Windows. When using this option, the WCF service uses Kerberos when in a domain or NTLM when deployed in a workgroup environment. This option uses the Windows token presented by the caller to authenticate against Active Directory. The service is authenticated by using the Windows credentials of the process identity.
• Username. When using this option, the caller provides a username and password to the service. The service can then authenticate against Windows, use a membership providers such as SqlMembershipProvider, or use a custom validator to validate against the custom store. You should choose this option only when Windows authentication is not possible. The service is authenticated with a service certificate.
• Certificate. When using this option, the caller presents an X.509 client certificate. The WCF service then looks up the certificate information on the host side and either validates it (peer trust) or trusts the issuer (chain trust) of the client certificate. This option should be used when Windows authentication is not possible, or in case of B2B scenarios. Service is authenticated with the service certificate.
• Issue token. When using this option, the client and service depend on STS to issue tokens that the client and service trust. CardSpace is a typical example of STS.

Authorization Options in WCF

WCF supports three basic authorization approaches:

• Role-based. Access to WCF operations is secured based on the role membership of the caller. Roles are used to partition your application’s user base into sets of users that share the same security privileges within the application; for example, Senior Managers, Managers, and Employees. Users are mapped to roles, and if the user is authorized to perform the requested operation, the application uses fixed identities with which to access resources. These identities are trusted by the respective resource managers; for example, databases, the file system, and so on.
• Identity-based. WCF supports an Identity Model feature, which is an extension of role-based authorization. Identity Model enables you to manage claims and policies in order to authorize clients. With this approach, you can verify claims contained within the authenticated users’ credentials. These claims can be compared with the set of authorization policies for the WCF service. Depending on the claims provided by the client, the service can either grant or deny access to the operation or resources. Identity Model is useful for fine-grained authorization and is most beneficial when using issue token authentication.
• Resource-based. Individual resources are secured by using Windows access control lists (ACLs). The WCF service impersonates the caller prior to accessing resources, which allows the operating system to perform standard access checks. All resource access is performed by using the original caller’s security context. This impersonation approach severely impacts application scalability, because it means that connection pooling cannot be used effectively within the application’s middle tier.

In enterprise-level applications where scalability is essential, a role-based or identity based approach to authorization represents the best choice. For small-scale intranet applications that serve per-user content from resources (such as files) that can be secured with Windows ACLs, a resource-based approach may be appropriate.