Solutions at a Glance

  • Article

patterns & practices Developer Center

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-related problems. This roadmap summarizes the solutions presented in this guide and provides links to appropriate material so that you can easily find the information you need and 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.

  • 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 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:

    1. Identify security code review objectives. Establish goals and constraints for the review.
    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.
    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.
    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.

  • How to perform security deployment inspections

    Inspect your service's run-time behavior and configuration. This includes your service's accounts, ports, and 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 dependent on, 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

    Use the following pattern to work through your authentication and authorization strategies:

    1. Identify your user stores.
    2. Identify your role stores.
    3. Identify resources you need to access and operations you need to perform.
    4. Identify which identities need to access the resources and perform the operations.
    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 the SQL Server membership provider
    • Windows authentication with Active Directory
    • Username authentication with a 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 the SQL Server membership provider
    • Basic authentication with Active Directory
    • Username authentication with a 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 role authorization using Windows groups.
    • If you are using Windows authentication, use SqlRoleProvider for role 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 AuthorizationStoreRoleProvider for role authorization.
    • If you are using username authentication with SqlMembershipProvider, use SqlRoleProvider for role authorization.
    • If you are using username authentication mapped to Windows, use WindowsTokeRoleProvider for role 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 AuthorizationStoreRoleProvider for role authorization.
    • If you are using certificate authentication with certificates mapped to Windows accounts, use WindowsTokeRoleProvider for role 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 AuthorizationStoreRoleProvider for role authorization.

  • How to choose effective strategies for authorization

    You can use the following resource access strategies:

    • Role-based. Map users to roles and check whether a role can perform the requested operation.
    • Identity-based. Authorize users based on their identity.
    • Claims-based. Grant or deny access to the operation or resources based on the client's claims.
    • Resource-based. 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. The trusted subsystem model 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 type. Consider the following:

    • Resource-based authorization considerations:

      • If you are using certificate 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 certificate 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 ASP.NET 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.

Auditing and Logging

  • How to enable auditing in WCF

    You can enable auditing in the configuration file.

  • 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 such 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 the WCF client and WCF service, use wsDualHttpBinding or netTcpBinding.

  • How to create a custom binding

    To create a custom binding, in the WCF configuration file, select 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 basicHttpBinding with username authentication to support legacy ASMX clients, and 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 you from exposing any other exception details to the clients.

    • Apply the FaultContract attribute directly on a contract operation, specifying the exception type that can be thrown as shown in the following example:

         [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 setting 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. Therefore 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 impersonation increases the potential attack surface of your application.

  • How to flow the original caller to the back end (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 (SPN) in Active Directory in order to associate the domain account with the HTTP service on your WCF server. You then configure your domain account in Active Directory to be trusted for delegation.

    Impersonate the original caller imperatively or declaratively—before you access the back-end resource, the original caller will be delegated to be authenticated and authorized at the back end.

Message Validation

  • How to perform parameter validation

    Use parameter inspectors to validate for length, range, format, and type. You can validate parameters on both 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. The following are the key steps you need to perform:

    1. Write a class that implements a parameter inspector.
    2. Write a class that implements endpoint behavior.
    3. Write a class that implements a behavior element.
    4. Add the behavior element as an extensibility point in the WCF configuration file.
    5. Create an endpoint behavior that uses the behavior element as an extensibility point.
    6. 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 will want to load the schema from the 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.

    The following are the key steps you need to perform:

    1. Write a class that implements Message Inspector.
    2. Write a class that implements endpoint behavior.
    3. Write a class that implements a behavior element.
    4. Add the behavior element as an extensibility point in the WCF configuration file.
    5. Create an endpoint behavior that uses the behavior element as an extensibility point.
    6. Configure the endpoint to use the endpoint behavior.