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

- J.D. Meier, Carlos Farre, Jason Taylor, Prashant Bansode, Steve Gregersen, Madhu Sundararajan, Rob Boucher

Summary

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

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 Tos

The Approach

The keys to building secure services include:
  • Identify your security objectives. This includes identifying your 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. From the threat model, developers address vulnerabilities, and testers verify that the developers closed the issues.
  • Apply proven principles, patterns, and practices. Principles, patterns, and practices are a good starting point. 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 scenario.
  • Apply effective security engineering throughout the life cycle. You should consider security throughout your application life cycle. You should start with security objectives. Threat modeling will help 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 patterns & practices Security Engineering approach includes specific security-related activities that help you meet your application security objectives.

SecuritySDLC.jpg

Summary of Key Security Engineering Activities

The 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 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 runtime characteristics of your application in the context of your infrastructure. Deployment reviews for security focus on evaluating your security design and configuration of your application, host, and network.

For more information on security engineering, see “patterns & practices Security Engineering Explained” - http://msdn.microsoft.com/en-us/library/ms998382.aspx

End-to-End Scenarios

Intranet

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

IntranetSoln.jpg

Internet

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

InternetSoln.jpg

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 where an entity proves the identity of another entity, typically through credentials, such as a user name 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 using cryptographic methods.
Message Replay Detection Message replay detection refers to identifying and rejecting messages that are re-submitted.
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 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, as well as 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 includes data integrity and confidentiality of your user and application data that you need to protect. 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 non-existent 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
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 Access 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 security of your Web services:

Category Description
Auditing and Logging Identify malign or malicious behavior; Know your baseline (what does good traffic look like); Instrument to expose behavior that can be watched (the big mistake here is typically app instrumentation is completely missing); Create a process to watch the logs and an escalation path for significant issues.
Authentication Use strong password policies; Don’t store credentials on the client side or in the clear on the server side; Encrypt communication channels to secure authentication tokens; use secure protocols such as HTTPs to secure authentication tokens.
Authorization Use least privilege accounts; Consider granularity of access; Enforce separation of privileges; Use role based access control.
Configuration Management Use least privileged service accounts; Don’t store credentials in plaintext; Use strong authentication and authorization on administrative interfaces; Don’t use the LSA; Avoid storing sensitive information in the web space or in or configuration files especially in the clear.
Exception Management Use structured exception handling (try-catch-finally); Only catch and wrap exceptions if the operation adds value/information; Don't reveal sensitive system or app info; Don't 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 ISS 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 and 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 and 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 Don’t store secrets in software; Enforce separation of privileges; Encrypt sensitive data over the wire; 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. http://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. http://msdn2.microsoft.com/en-us/library/aa480560.aspx
Brokered Authentication: Kerberos Use the Kerberos protocol to broker authentication between clients and Web services. http://msdn2.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) to verify the credentials presented by the requesting application. http://msdn2.microsoft.com/en-us/library/aa480565.aspx
Brokered Authentication: STS Use brokered authentication with a security token issued by a Security Token Service (STS). The STS is trusted by both the client and the Web service to provide interoperable security tokens. http://msdn2.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. http://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. http://msdn2.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. http://msdn2.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. http://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. http://msdn2.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). http://msdn2.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. http://msdn2.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. http://msdn2.microsoft.com/en-us/library/aa480606.aspx

Bindings in WCF

The following table summarizes common bindings in WCF:

Binding Description
basicHttpBinding It represents a bindings that configures and expose endpoints that are able to communicate with ASMX-based Web services and clients and other services that conform to the WS-I Basic Profile 1.1. By defaults 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 runtime 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, optimized for on-machine cross process communication. By default, it generates a runtime 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 implementing 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 ws2007FederationHttpBinding. Defines a binding that derives from wsFederationHttpBinding and supports federated security. It helps implementing 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 standard for OASIS (Organization for the Advancement of Structured Information Standards)
wsDualHttpBinding Defines a secure, reliable and interoperable binding that is suitable for duplex service contracts or communication through 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 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 their own mechanism for passing credentials and handling message protection. The most common approach for this 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.

TransportSec.jpg

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 service and client in an intranet.

Using transport security has the following advantages:
  • Provides interoperability, communicating parties does not need to understand WS-Security.
  • It may result in better performance.
  • Hardware accelerators can be used to further improve the 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 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 client and service agree.

MessageSec.jpg

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 has following advantages:
  • Provides End-to-end security, as 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 the overall application performance.
  • Message security is transport independent and can be used with any transport protocol.
  • Support for a wide set of credentials and claims, including issue token which enables federated security.
Using message security has following disadvantages:
  • This option may reduce performance compared to transport security as each individual message is encrypted and signed.
  • Does not support interoperability with older ASMX clients as 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 WCF service does not authenticate the callers, this is not the recommended option from security perspective. You should avoid using this option wherever possible.
  • Basic. This option is available with http protocol only and the client is authenticated using username and password against Active Directory. The client credentials are transported using Base64 encode string, which is literally like clear string, therefore it is not the most secure option. The service is authenticated by the SSL certificate used for secure communication.
  • NTLM. This option is available with http protocol only. The client is authenticated 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 using the Windows credentials of the process identity or 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. The Service is authenticated 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 which the WCF service either and validates with peer trust or trusts based on the issuer of the certificate. This option should be used when Windows Authentication is not possible such as in the case of B2B scenarios. The service is authenticated with the Service Certificate or 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 WCF service does not authenticate the callers, this is not the recommended option from security perspective. You should avoid using this option wherever possible.
  • Windows. When using this option WCF service uses Kerberos when in a domain else NTLM when deployed in workgroup environment. This option uses windows token presented by the caller to authenticate against the Active Directory. Service is authenticated using the windows credentials of the process identity.
  • UserName. When using this option, the caller provides username and password to the service and the service can authenticate against windows, or use membership providers like SqlMembershipProvider or use 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 a X.509 client certificate, WCF service looks up the certificate information on the host side and 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 for some reason or in case of B2B scenarios. Service is authenticated with Service Certificate.
  • Issue Token. When using this option the client and the service depends on the Secure Token Service to issue tokens that the client and service trusts. CardSpace is a typical example of STS.

Authorization Options in WCF

WCF supports three basic authorization approaches as discussed below:
  • 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 to role-based authorization. Identity Model enables you to manage claims and policies 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 upon the claims provided by the client the service can grant or deny access to the operation or resources. Identity model is useful fore fine grained authorization and is most best beneficial when using issue token authentication.
  • Resource based. Individual resources are secured using Windows 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 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.

Last edited Jun 11, 2008 at 12:52 AM by prashantbansode, version 3

Comments

No comments yet.