Chapter 1: Security Fundamentals for Web Services
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
- For more information on security engineering, see patterns & practices Security Engineering Explained.
- For more information on threat modeling, see Threat Modeling Web Applications.
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
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 |
|
Authentication |
|
Authorization |
|
Configuration Management |
|
Exception Management |
|
Impersonation/Delegation |
|
Message Encryption |
|
Message Replay Detection |
|
Message Signing |
|
Message Validation |
|
Sensitive Data |
|
Session Management |
|
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. |
|
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. |
|
Brokered Authentication: Kerberos |
Use the Kerberos protocol to broker authentication between clients and Web services. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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). |
|
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. |
|
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. |
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:
- For more information on applying security throughout the life cycle, see patterns & practices Security Engineering Explained.
- For more information on how to perform effective threat modeling, see patterns & practices Threat Modeling Web Applications.
- For more information on Web Services Security patterns, see patterns & practices Web Services Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0.