Solutions at a Glance

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

Summary

This chapter provides an at-a-glance roadmap into the various solutions presented in this guide. Use this chapter to find fast answers to common WCF security problems. This roadmap summarizes the solution presented in this guide and provides links to appropriate material so you can easily find the information you need and find solutions to specific problems.

Security Engineering

  • How to identify and evaluate threats
Use threat modeling to systematically identify threats rather than applying security in a haphazard manner. Next, rate the threats based on the risk of an attack or occurrence of a security compromise and the potential damage that could result. This allows you to tackle threats in the appropriate order.

For more information about creating a threat model and evaluating threat risks, see “Threat Modeling Web Applications” at http://msdn.microsoft.com/en-us/library/ms978516.aspx .
  • How to create secure designs
Use tried and tested design principles. Focus on the critical areas where the correct approach is essential and where mistakes are often made. This guide refers to these as application vulnerability categories. They include input validation, authentication, authorization, configuration management, sensitive data protection, session management, cryptography, parameter manipulation, exception management, and auditing and logging considerations. Pay serious attention to deployment issues including topologies, network infrastructure, security policies, and procedures.

You can use the end-to-end application scenarios in this guide to help identify candidate authentication and authorization strategies.
  • How to perform an design inspections
Review your application's design in relation to the target deployment environment and associated security policies. Consider the restrictions imposed by the underlying infrastructure layer security, including perimeter networks, firewalls, remote application servers, and so on. Use application vulnerability categories to help partition your application, and analyze the approach taken for each area.

You can use the guidelines in this guide to create customized guidelines for your teams.
  • How to perform security code inspections
You can use the following general technique for performing security inspections:
  • Step 1. Identify security code review objectives. Establish goals and constraints for the review.
  • Step 2. Perform a preliminary scan. Use static analysis to find an initial set of security issues and to improve your understanding of where you will be most likely to find security issues when you review the code more fully.
  • Step 3. Review the code for security issues. Review the code thoroughly with the goal of finding security vulnerabilities that are common to many applications. You can use the results of step 2 to focus your analysis.
  • Step 4. Review for security issues unique to the architecture. Complete a final analysis by looking for security issues that relate to the unique architecture of your application. This step is most important if you have implemented a custom security mechanism or any feature designed specifically to mitigate a known security threat.

For more information on performing code inspections, see “How To: Perform a Code Review for Managed Code (“Baseline Activity”)” at http://msdn.microsoft.com/en-us/library/ms998364.aspx.
  • How to perform security deployment inspections
Inspect your services runtime behavior and configuration. This includes your services accounts, ports, protocols.

Message and Transport Security

  • How to choose between message and transport security
The transport-level security model is simple, well understood, and adequate for many (primarily intranet-based) scenarios, in which the transport mechanisms and endpoint configuration can be tightly controlled.

The main issues with transport-level security are:
  • Security becomes tightly coupled to, and dependant upon, the underlying platform, transport mechanism, and security service provider (NTLM, Kerberos, and so on).
  • Security is applied on a point to point basis, with no provision for multiple hops and routing through intermediate application nodes.
  • Because the entire message needs to be encrypted, this approach can be costly.

Message-level security:
  • Can be independent from the underlying transport
  • Enables a heterogeneous security architecture
  • Provides end-to-end security and accommodates message routing through intermediate application nodes
  • Supports multiple encryption technologies
  • Supports non-repudiation

Authentication / Authorization

  • How to design an effective authentication and authorization strategy
Here’s a pattern for working through your authentication and authorization strategies:
  • Step 1. Identify your user stores.
  • Step 2. Identify your role stores.
  • Step 3. Identify resources you need to access and operations you need to perform.
  • Step 4. Identify which identities need to access the resources and perform the operations.
  • Step 5. Choose your authentication and authorization strategies.
  • How to authenticate users for Intranet applications
The most common scenarios for intranet applications include any of the following patterns:
  • Username authentication with SQL Membership Provider.
  • Windows authentication with Active Directory.
  • Username authentication with Custom Store.
  • Certificate authentication with Windows.
  • How to authenticate users for Internet applications
The most common scenarios for internet applications include any of the following patterns:
  • Username authentication with SQL Membership Provider.
  • Basic authentication with Active Directory.
  • Username authentication with Custom Store.
  • Certificate authentication with Windows.
  • How to authorize callers to perform operations and access resources
Consider the following options:
  • If you are using Windows authentication, use WindowsTokeRoleProvider for roles authorization using Windows groups.
  • If you are using Windows authentication, use SqlRoleProvider for roles authorization.
  • If you are using Windows authentication, use AzMan policy store in an XML file, in Active Directory, or in Active Directory Application Mode (ADAM), consider using the AuthorizationStoreRoleProvider for roles authorization.
  • If you are using Username authentication with SqlMembershipProvider, use SqlRoleProvider for roles authorization.
  • If you are using Username authentication mapped to Windows, use WindowsTokeRoleProvider for roles authorization using Windows groups.
  • If you are using Username authentication mapped to Windows, use AzMan policy store in an XML file, in Active Directory, or in Active Directory Application Mode (ADAM), consider using the AuthorizationStoreRoleProvider for roles authorization.
  • If you are using Certificate Authentication with certificates mapped to Windows accounts, use WindowsTokeRoleProvider for roles authorization using Windows groups.
  • If you are using Certificate Authentication with certificates mapped to Windows accounts, use AzMan policy store in an XML file, in Active Directory, or in Active Directory Application Mode (ADAM), consider using the AuthorizationStoreRoleProvider for roles authorization.
  • How to choose effective strategies for authorization
You can use the following resource access strategies:
  • Role-based. With roles, you map users to roles and check whether a role can perform the requested operation.
  • Identity-based. With identity-based, you authorize users based on their identity.
  • Claims-based. With claims-based, you grant or deny access to the operation or resources based on the client's claims.
  • Resource-based. With resource-based, you protect resources using Access Control Lists (ACLs.)
  • How to choose between trusted subsystem and impersonation/delegation
With the trusted subsystem model, you use the process identity to access downstream network resources such as databases. With impersonation/delegation, you use impersonation and use the original caller's identity to access the database. Trusted subsystem offers better scalability because your application benefits from efficient connection pooling. You also minimize back-end ACL management. Only the trusted identity can access the database. Your end users have no direct access. In the trusted subsystem model, the service is granted broad access to back-end resources. As a result, a compromised service could potentially make it easier for an attacker to gain broad access to back-end resources. Keeping the service account's credentials protected is essential. With impersonation/delegation, you benefit from operating system auditing because you can track which users have attempted to access specific resources. You can also enforce granular access controls in the database, and individual user accounts can be restricted independently of one another in the database.
  • How to choose between resource-based and role-based authorization
Your authorization strategy may also be influenced by your choice of authentication. Consider the following:

Resource-based authorization considerations:
  • If you are using certificates authentication you will need to map certificates to Windows groups.
  • If you are using username authentication you will need to perform protocol transition.
  • Windows authentication will work with resource-based authorization by default.
  • Basic authentication will work with resource-based authorization by default.
  • Note: You need to impersonate for resource-based authorization.

Role-based authorization considerations:
  • If you are using certificates authentication you will need to map certificates to Windows groups.
  • If you are using username authentication with Windows groups, you will need to perform protocol transition.
  • Username authentication will work with ASPNET roles by default.
  • Windows authentication will work with Windows groups by default.
  • Basic authentication will work with Windows groups by default.

Patterns

  • How to leverage Web Services security patterns
Familiarize yourself with the following patterns, then evaluate and apply the patterns when they make sense for your particular scenario:
  • Brokered Authentication
  • Brokered Authentication: Kerberos
  • Brokered Authentication: X509 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

For information on the patterns above, see the patterns & practices “Web Services Security” guide at http://msdn.microsoft.com/en-us/library/aa480545.aspx .

Auditing and Logging

  • How to enable auditing in WCF
You can enable auditing in the configuration.
  • How to instrument your WCF service
You can use ASP.NET Health Monitoring.
  • How to improve your auditing in WCF
Audit for the following:
  • User management events. Instrument your application and monitor user management events such as password resets, password changes, account lockout, user registration, and authentication events. Doing this helps you to detect and react to potentially suspicious behavior. It also enables you to gather operations data; for example, to track who is accessing your application and when user account passwords need to be reset.
  • Unusual or suspicious activity. Instrument your application and monitor events that might indicate unusual or suspicious activity. This enables you to detect and react to potential problems as early as possible. Unusual activity could include replays of old authentication tickets or too many login attempts over a specific period of time.
  • Significant business operations. Track significant business operations. For example, instrument your application to record access to particularly sensitive methods and business logic.

Bindings

  • How to choose the right WCF binding?
Consider the following scenarios:
  • If you need to support clients over the internet, consider using wsHttpBinding
  • If you need to expose your WCF service to legacy clients as an ASMX web service, use basicHttpBinding
  • If you need to support WCF clients within an intranet, consider using netTcpBinding
  • If you need to support WCF clients on the same machine, consider using netNamedPipeBinding
  • If you need to support disconnected queued calls, use netMsmqBinding
  • If you need to support bidirectional communication between WCF Client and WCF service, use wsDualHttpBinding or netTcpBinding
  • How to create a custom binding?
You create a custom binding by selecting in the WCF configuration file a set of binding elements that are supposed to be constructed in a specific order. Those binding elements refer to transaction, reliable message, security, encoding formats and transport protocol.

  • How to support multiple authentication and authorization strategies?
Use multiple bindings to support multiple authentication and authorization strategies. For instance you could use a basicHttpBinding with username authentication to support legacy ASMX clients and a wsHttpBinding with Windows authentication to support newer WCF-enabled clients.

Exception Management

  • How to handle exceptions in WCF
Use fault contracts to handle exceptions in WCF. By using the FaultContract attribute in a service contract you can specify the possible faults that can occur in your WCF service. This prevents exposing any other exception details to the clients.
  • Apply the fault contract attribute directly on a contract operation specifying the exception type that can be thrown.
   [OperationContract]
   [FaultContract(typeof(DivideByZeroException))]
   double Divide(double number1,double number2);

Impersonation / Delegation

  • How to impersonate at the service level
You can impersonate the entire service by applying the impersonateCallerForAllOperations attribute to "true" in the WCF configuration file. If you are impersonating all operations in the service, the Impersonation property of the OperationBehaviorAttribute applied to each operation will override. So if the property on the operation is set to something other than Allowed or Required, impersonation will be turned off for that operation.
  • How to impersonate at the operation level
You can impersonate declaratively by applying the OperationBehavior attribute on any operation that requires client impersonation. Use impersonation selectively and only on the operations that need it since by nature it increases the potential attack surface of your application.
  • How to flow the original caller to the backend (double hop)
If your WCF Service runs under the Network Service account, configure your computer account in Active Directory to be trusted for delegation. If your application runs under a custom domain account, you must register a service principal name in Active Directory to associate the domain account with the HTTP service on your WCF server. Then configure your domain account in Active Directory to be trusted for delegation.
Impersonate the original caller imperatively or declaratively – before you access the backend resource, the original caller will be delegated to be authenticated and authorized at the backend.

Message Validation

  • How to perform parameter validation
Use parameter inspectors to validate for length, range, format and type. You can validate parameters both on the client and the service. The server should not trust client-side validation, but you can use it to reduce round-trips for incorrect input. Following are the key steps you need to perform:
  • Write class that implements parameter inspector.
  • Write class that implements endpoint behavior.
  • Write class that implements behavior element.
  • Add the behavior element as an extensibility point in WCF configuration file.
  • Create an endpoint behavior that uses the behavior element as an extensibility point.
  • Configure the endpoint to use the endpoint behavior.
  • How to perform message validation
Use schemas and regular expressions to validate for length, range, format and type. Schemas are preferred for validating complex types (classes and message contracts.). For performance reasons, you'll want to load the schema from cache (in the Message Inspector). You can validate incoming and outgoing messages on the server side as well as incoming and outgoing messages on the client-side. The server should not trust client-side validation, but you can use it to reduce round-trips for incorrect input.
Following are the key steps you need to perform:
  • Write class that implements Message inspector.
  • Write class that implements endpoint behavior.
  • Write class that implements behavior element.
  • Add the behavior element as an extensibility point in WCF configuration file.
  • Create an endpoint behavior that uses the behavior element as an extensibility point.
  • Configure the endpoint to use the endpoint behavior.

Last edited Jun 11, 2008 at 12:36 AM by prashantbansode, version 2

Comments

No comments yet.