Chapter 1: Security Fundamentals for Web Services

  • Article

patterns & practices Developer Center

Contents

  • What Do We Mean by Security?
  • The Foundations of Security
  • Threats, Vulnerabilities, and Attacks Defined
  • What Is a Service?
  • Common Services Scenarios
  • Service-Oriented Architecture (SOA)
  • SOA Tenets
  • Service Orientation vs. Object Orientation
  • Application Boundaries
  • Enterprise SOA vs. Application SOA
  • SOA Security in Practice
  • WS-Security Standards / Web Services Security Concepts
  • How Do You Build Secure Services?
  • patterns & practices Security Engineering
  • Web Services Security Principles
  • Web Services Security Frame
  • Web Services Security Patterns

Objectives

  • Understand the key security requirements.
  • Understand the difference between threats, attacks, vulnerabilities, and countermeasures.
  • Understand the key distinctions for Service-Oriented Architecture (SOA).
  • Understand the Web Services Security Frame.
  • Understand the key principles and patterns for building secure services.

Overview

Building secure services includes knowing the threats you face, making effective trade-offs, and integrating security throughout your software development life cycle. One of the most effective ways to deal with security is to leverage proven principles, patterns, and practices. The key is to know which principles, patterns, and practices are effective for your particular situation. Techniques such as threat modeling and security inspections can you help you shape your software to meet your specific security objectives.

What Do We Mean by Security?

Security is fundamentally about protecting assets. Assets may be tangible items, such as operations or your customer database — or they may be less tangible, such as your company’s reputation.

It is important to recognize that security is a path, not a destination. As you analyze your infrastructure and applications, you identify potential threats and understand that each threat presents a degree of risk. Security is about risk management and implementing effective countermeasures. One of the most important concepts in security is that effective security is a combination of people, process, and technology.

The Foundations of Security

Security relies on the following elements:

  • Authentication. Authentication addresses the question: who are you? It is the process of uniquely identifying the clients of your applications and services. These might be end users, other services, processes, or computers. In security parlance, authenticated clients are referred to as principals.
  • Authorization. Authorization addresses the question: what can you do? It is the process that governs the resources and operations that the authenticated client is permitted to access. Resources include files, databases, tables, rows, and so on, together with system-level resources such as registry keys and configuration data. Operations include performing transactions such as purchasing a product, transferring money from one account to another, or increasing a customer’s credit rating.
  • Auditing. Effective auditing and logging is the key to non-repudiation. Non-repudiation guarantees that a user cannot deny performing an operation or initiating a transaction. For example, in an e-commerce system, non-repudiation mechanisms are required to make sure that a consumer cannot deny ordering 100 copies of a particular book.
  • Confidentiality. Confidentiality, also referred to as privacy, is the process of making sure that data remains private and confidential, and that it cannot be viewed by unauthorized users or eavesdroppers who monitor the flow of traffic across a network. Encryption is frequently used to enforce confidentiality. Access control lists (ACLs) are another means of enforcing confidentiality.
  • Integrity. Integrity is the guarantee that data is protected from accidental or deliberate (malicious) modification. Like privacy, integrity is a key concern, particularly for data passed across networks. Integrity for data in transit is typically provided by using hashing techniques and message authentication codes.
  • Availability. From a security perspective, availability means that systems remain available for legitimate users. The goal for many attackers with denial of service (DoS) attacks is to crash an application or to make sure that the application is sufficiently overwhelmed so that other users cannot access it.

Threats, Vulnerabilities, and Attacks Defined

When thinking about security, it is helpful to think in terms of assets, threats, vulnerabilities, and attacks.

  • Asset. An asset is something related to your application that is worth protecting. Sensitive data, intellectual property, and access to critical operations are all assets. For example, user credit card numbers are an asset worth protecting in your application.
  • Threat. A threat is any potential occurrence, malicious or otherwise, that could harm an asset. In other words, a threat is any bad thing that can happen to your assets.
  • Vulnerability. A vulnerability is a weakness that makes a threat possible. This may be because of poor design, configuration mistakes, or inappropriate and insecure coding techniques. Weak input validation is an example of an application layer vulnerability, which can result in input attacks.
  • Attack. An attack is an action that exploits vulnerability or enacts a threat. Examples of attacks include sending malicious input to an application, or flooding a network in an attempt to deny service.

To summarize, a threat is a potential event that can adversely affect an asset, whereas a successful attack exploits vulnerabilities in your system.

What Is a Service?

A service is a public interface that provides access to a unit of functionality. Services literally provide some programmatic ‘service’ to the caller who consumes them. Services are loosely coupled and can be combined from within a client or from within other services to provide more complex functionality. Services are distributable and can be accessed from a remote machine as well as from the local machine on which they are running. Services are message-oriented, meaning that service interfaces are defined by a Web Services Description Language (WSDL) file and operations are called using XML-based message schemas that are passed over a transport. Services support a heterogeneous environment by focusing interoperability at the message/interface definition. If components can understand the message and interface definition, they can use the service regardless of their base technology.

Common Services Scenarios

Services are flexible by nature and can be used in a wide variety of scenarios and combinations. The following are key scenarios that we will return to many times over the course of this guide:

  • Service exposed over the Internet. This scenario describes a service that is consumed by Web applications or smart client applications over the Internet. Authentication and authorization decisions have to be made based upon Internet trust boundaries and credentials options. For example, username authentication is more likely in the Internet scenario than the intranet scenario. This scenario includes business-to-business as well as consumer-focused services. For example, a Web site that allows scheduling of your family’s doctor visits could be included in this scenario.
  • Service exposed over an intranet. This scenario describes a service that is consumed by Web applications or smart client applications over an intranet. Authentication and authorization decisions have to be made based upon intranet trust boundaries and credentials options. For example, an Active Directory user store is more likely in the intranet scenario than in the Internet scenario. An enterprise Web-mail application could be included in this scenario.
  • Service exposed on the local machine. This scenario describes a service that is consumed by an application on the local machine. Transport and message protection decisions must be based on local machine trust boundaries and users.
  • Mixed scenario. This scenario describes a service that is consumed by multiple applications over the Internet, an intranet, and/or the local machine. For example, a line-of-business (LOB) application that is consumed internally by a thick client application and over the Internet by a Web application could be included in this scenario.

Service-Oriented Architecture (SOA)

Service-Oriented Architecture (SOA) is an architecture of loosely coupled components that can be distributed across platform, technology, and physical topologies. Service components can be combined to provide a business process, or to provide more complex services for a client application. Services are the preferred communication technique across application boundaries, including platform, deployment, and trust boundaries.

The key attributes of SOA are:

  • Interoperable. Components can be interoperable across platform and technology boundaries.
  • Componentized. Services are exposed as autonomous components that can be versioned and managed independently.
  • Composable. Services can be composed by an application to perform more complex operations or to enact a business process.
  • Message-based interfaces. Interfaces are defined by message contracts and schemas. Operation calls and parameters are passed in XML message envelopes.
  • Distributable. Service components can be consumed from the same machine or distributed to remote machines. The service interface and logic is independent of the transport and protocol used to access the service.
  • Discoverable. Services publish their metadata as WSDL so that client applications can discover the interfaces and schemas and generate a client-side proxy to consume the service.

SOA Tenets

You can further define the SOA attributes based on a set of four SOA tenets. Microsoft architect Don Box was the first to provide this set of design tenets that govern SOA:

  • Boundaries are explicit. Operations are called over well-defined boundaries, passing explicitly defined messages.
  • Services are autonomous. Each service is maintained, developed, deployed, and versioned autonomously.
  • Services share schemas and contracts, not class. Services share contracts and schemas to communicate.
  • Compatibility is based upon policy. Policy in this case means definition of transport, protocol, security, etc.

Service Orientation vs. Object Orientation

Services are the preferred communication technique to use across application boundaries, including platform, deployment, and trust boundaries. If you are building a distributed application, consider using a service-oriented approach. Although object orientation provides a pure view of what a system should look like and is effective for producing logical models, an object-based approach can fail to consider real-world factors, such as physical distribution, trust boundaries, and network communication, as well as nonfunctional requirements, such as performance and security.

Object orientation

Service orientation

Assumes a homogeneous platform and execution environment.

Assumes a heterogeneous platform and execution environment.

Shares types, not schemas.

Shares schemas, not types.

Assumes cheap, transparent communication.

Assumes variable cost, explicit communication.

Objects are linked: object identity and lifetime are maintained by the infrastructure.

Services are autonomous: security and failure isolation are a necessity.

Typically requires synchronized deployment of both client and server.

Allows continuous, separate deployment of client and server.

Is easy to conceptualize and thus provides a natural model to follow.

Builds on ideas from component software and distributed objects. Dominant theme is to manage/reduce sharing between services.

Provides no explicit guidelines for state management and ownership.

Owns and maintains state or uses the reference state.

Assumes a predictable sequence, timeframe, and outcome of invocations.

Assumes message-oriented, potentially asynchronous, and long-running communications.

Goal is to transparently use functions and types remotely.

Goal is to provide inter-service isolation and wire interoperability based on standards.

Application Boundaries

Common application boundaries include platform, deployment, trust, and evolution boundaries. (Evolution refers to whether or not you develop and upgrade applications together.) When evaluating architecture and design decisions that affect your application boundaries, consider the following:

  • Objects and remote procedure calls (RPC) are appropriate within boundaries.
  • Services are appropriate across and within boundaries.

Enterprise SOA vs. Application SOA

Because SOA is an architectural style, it can be helpful to think of SOA in terms of two different scopes. For the purposes of this guide, we factor SOA in terms of individual application scenarios and larger enterprise scenarios.

Enterprise SOA

At the enterprise level, you consider SOA from the standpoint of your enterprise architecture. This is where your enterprise architects come into play. The following are key SOA considerations at the enterprise level:

  • How can you compose application services to create a business process?
  • What is your portfolio of capabilities that are candidates for services?
  • How can you push common application features to a common services infrastructure?
  • How can you provide common services across your portfolio of applications?
  • How can you connect your heterogeneous systems through common services?
  • How can you provide a common security infrastructure for your services?

Application SOA

At the application level, you consider SOA from the standpoint of your application’s architecture and architectural style. This is where your application architects come into play. The following are key SOA considerations at the application level:

  • How can you design, create, and consume services within your application?
  • How can you leverage service-oriented approaches within your application’s architecture?
  • How can you design for effective message-oriented communication?

This guides focuses on application-level SOA.

SOA Security in Practice

Effective SOA security in practice includes the following measures:

  • Coordinating people, process, and technology.
  • Integrating and leveraging various levels of standards (general security standards, XML security standards, Web services security standards).
  • Integrating and leveraging various user stores and role stores.
  • Making trade-offs between user experience, technical, and business perspectives.

WS-Security Standards / Web Services Security Concepts

The WS-* architecture is a set of standards-based protocols designed to secure Web service communication. The WS-* security standards include:

  • WS-Policy. WS-Policy allows Web services to define policy requirements for endpoints. These requirements include privacy rules, encryption rules, and security tokens.
  • WS-Security. WS-Security allows Web services to apply security to Simple Object Access Protocol (SOAP) messages through encryption and integrity checks on all or part of the message.
  • WS-Trust. WS-Trust allows Web services to use security tokens to establish trust in a brokered security environment.
  • WS-SecureConversation. WS-SecureConversation builds on top of WS-Policy, WS-Security, and WS-Trust to enable secure communications between client and service.
  • WS-ReliableMessaging. WS-ReliableMessaging allows Web services and clients to trust that when a message is sent, it will be delivered to the intended party.
  • WS-AtomicTransactions. WS-AtomicTransactions allows transaction-based Web services in which transactions can be rolled back in the event of a failure.

How Do You Build Secure Services?

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 particular 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. Using 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 for building secure services. 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 application life cycle. You should consider security throughout your application life cycle. You should start with 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.

Additional Resources

patterns & practices Security Engineering

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

Ff648318.CH01-Fig1(en-us,PandP.10).png

Figure 1
Key Security Engineering Activities

Summary of Key Security Engineering Activities

This 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 run-time 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.

Web Services Security Principles

Recommendations made throughout this guide are based on a core set of security principles. These principles have proven effective across many different technologies and scenarios, including Web services in SOA. Use the following list to apply a principle-based approach to Web service security when building your WCF application.

Principle

Concept

Apply defense in depth

Use multiple gatekeepers to keep attackers at bay. Defense in depth means you do not rely on a single layer of security, or you consider that one of your layers may be bypassed or compromised.

Check at the gate

Authenticate and authorize callers early—at the first gate.

Compartmentalize

Isolate and contain a problem. Apply the principle of separation of concerns. If an attacker takes over your application, what resources can he or she access? Can an attacker access network resources? How are you restricting potential damage? Firewalls, least-privileged accounts, and least-privileged code are examples of compartmentalizing.

Create secure defaults

Is the default account set up with least privilege? Is the default account disabled by default and then explicitly enabled when required? Does the configuration use a password in plaintext? When an error occurs, does sensitive information leak back to the client, to potentially be used against the system?

Do not trust user input

Keep user input out of the control path. Your application’s user input is the attacker’s primary weapon when targeting your application. Assume that all input is malicious until proven otherwise, and apply a defense-in-depth strategy to input validation, taking particular precautions to make sure that input is validated whenever a trust boundary in your application is crossed. You need to validate input at both entry points and exit points in your application.

Establish trust boundaries

Trust boundaries indicate where trust levels change. You can think of trust from the perspective of confidentiality and integrity. For example, a change in access control levels in your application, where a specific role or privilege level is required to access a resource or operation, would be a change in trust level. Another example would be at an entry point in your application where you might not fully trust the data passed to the entry point. Identify trust boundaries from a data flow perspective. For each subsystem, consider whether the upstream data flow or user input is trusted, and if it is not, consider how the data flow and input can be authenticated and authorized. Knowing which entry points exist between trust boundaries allows you to focus your threat identification on these key entry points. For example, you are likely to have to perform more validation on data passed through an entry point at a trust boundary.

Fail securely

If an application fails, do not leave sensitive data accessible. Return friendly errors to end users that do not expose internal system details. Do not include details that may help attackers exploit vulnerabilities in your application.

Reduce your attack surface

If you do not use it, remove it or disable it. Reduce the surface area of attack by disabling or removing unused services, protocols, and functionality. Does your server need all those services and ports? Does your application need all those features?

Secure the weakest link

Is there vulnerability at the network layer that an attacker can exploit? What about the host? Is your application secure? Any weak link in the chain is an opportunity for breached security.

Use least privilege

By running processes using accounts with minimal privileges and access rights, you significantly reduce the capabilities of an attacker if the attacker manages to compromise security and run code.

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 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 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.

Using the Web Services Security Frame

The Web Services Security Frame serves as a foundation for the rest of this guide. Guidelines, checklists, and other guidance are all organized around the categories represented in this frame. You can use this frame to help wrap your mind around WCF security and better organize the key decisions you need to make when considering security for your application. Through practice and experience, we have learned that the frame is most useful when combined with a question-driven approach to security. This approach will help you transition from security understanding to actionable steps you can take to improve the security stance of your application.

Category

Key questions

Auditing and Logging
  • What events are important for the security of your application?
  • In the event of an attack, what trail of evidence would you want left behind for your investigation?
  • What user management or sensitive business operations do you want to track?

Authentication
  • What credentials will your users present to your service?
  • From what types of clients and locations (Internet versus intranet) will they be calling?
  • How do you want to store user account information?
  • Do you want to map authentication to pre-existing Windows accounts in your domain?

Authorization
  • What roles will be defined for your service?
  • What operations in your service should require explicit authorization?
  • Do you want to authorize the original caller in your service, before your service, or in the business layers called by your service?
  • Do you need to use the original caller to access resources on the back end?
  • Where do you want to store role information?
  • Do you already have roles defined, such as Windows groups, that you want your service to interact with?

Configuration Management
  • Under what security context does your application run?
  • Which databases does it connect to and under what security context?
  • How is your application administered?
  • What settings are sensitive and should be secured?

Exception Management
  • When a method call in your application fails, what does your application do?
  • How much do you reveal?
  • Do you return friendly error information to end users?
  • Do you pass valuable exception information back to the caller?
  • Does your application fail gracefully?

Impersonation/Delegation
  • What tiers and layers of your application need access to the original caller’s identity and credentials?
  • Do you need to flow the original caller to back-end resources?
  • Do you need to authorize the original caller at the service level or in a downstream component?
  • Do you need to access the database using the original caller’s security context?
  • Which operations in your service will need to use impersonation to flow the original caller’s identity?

Message Encryption
  • Is there sensitive data transmitted in your messages that needs to be protected from exposure to an attacker?

Message Replay Detection
  • How do you protect a service from an attacker who replays an intercepted message?

Message Signing
  • Is it important that the message source can be verified and that the contents have not been modified?

Message Validation
  • How will you validate incoming SOAP messages on your service?
  • How will you validate input parameters on your service?
  • How will you validate information that is returned to your client?
  • How will you validate data that comes from other sources such as your database or the file system?
  • How will you make your outbound data safe?

Sensitive Data
  • How does your application handle sensitive data? (Sensitive data refers to any data that must be protected either in memory, over the network, or in persistent stores, and how your application handles that data.)
  • How are you keeping secrets (confidentiality)?
  • How are you tamper-proofing your data or libraries (integrity)?
  • How are you providing seeds for random values that must be cryptographically strong? (Cryptography refers to how your application enforces confidentiality and integrity.)

Session Management
  • How does your application handle and protect client sessions?

Web Services Security Patterns

The following Web services security patterns from the Microsoft patterns & practices Web Services Security guide are helpful for addressing various security concerns, such as authentication, authorization, etc.

  • Brokered Authentication
  • Brokered Authentication: Kerberos
  • Brokered Authentication: X.509 PKI
  • Brokered Authentication: STS
  • Data Confidentiality
  • Data Origin Authentication
  • Direct Authentication
  • Exception Shielding
  • Message Replay Detection
  • Message Validator
  • Perimeter Service Router
  • Protocol Transition with Constrained Delegation
  • Trusted Subsystem

Web Services Security Patterns Organized by the Web Services Security Frame

The following table summarizes the Web Services Security patterns organized by the Web Services Security Frame.

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: X.509 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.

https://msdn.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.

https://msdn.microsoft.com/en-us/library/aa480563.aspx

Authorization

Protocol Transition with Constrained Delegation

Use the Kerberos protocol extensions in Microsoft 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 ciphertext. Data is encrypted with an algorithm and a cryptographic key. Ciphertext 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

Summary

The foundations of WCF security include authentication, authorization, auditing, confidentiality, integrity, and availability. When you think about security in your service, you should first understand the distinctions between threats, attacks, vulnerabilities, and countermeasures. To build secure services, you will identify your security objectives; identify your threats and vulnerabilities; apply principles, patterns, and practices; and use security engineering techniques throughout your application life cycle. By using the Web Services Security Frame, you can better organize and use your security knowledge.

Additional Resources

For more information, see the following resources: