WCF Security Guidelines

patterns & practices Developer Center

Index

Design Considerations

  • Consider exposing different endpoints
  • If you need to support ASMX clients, use basicHttpBinding
  • If you are migrating from DCOM, use netTcpBinding
  • If you need to support legacy WSE clients, use a customBinding in WCF
  • If you require interoperability with non-Microsoft clients, use bindings that are targeted for interoperability
  • If your non-Microsoft clients understand the WS* stack, use ws2007HttpBinding or wsHttpBinding
  • Consider transport security as your preferred security mode
  • Know your authentication options
  • Know your authorization options
  • Know your binding options
  • Choose the right binding for your scenario

Auditing and Logging

  • Use WCF auditing to audit your service
  • If non-repudiation is important, consider setting the SuppressAuditFailure property to false
  • Use message logging for debugging purposes
  • Instrument for user management events
  • Instrument for significant business operations
  • Protect log files from unauthorized access
  • Do not log sensitive information
  • Protect information in log files
  • Use a custom trace listener only when message filtering is needed

Authentication

  • Know your authentication options
  • Use Windows authentication when you can
  • If your users are in Active Directory but you can't use Windows authentication, consider using usernam authentication
  • If you are using usernam authentication, use a membership provider instead of custom authentication
  • If your users are in a SQL membership store, use the SQL Server membership provider
  • If your users are in a custom store, consider using usernam authentication with a custom validator
  • If your clients have certificates, consider using client certificate authentication
  • If your partner applications need to be authenticated when calling WCF services, use client certificate authentication
  • If you are using usernam authentication, validate user login information
  • Do not store passwords directly in the user store
  • Enforce strong passwords
  • Protect access to your credential store
  • If you are using client certificate authentication, limit the certificates in the certificate store

Authorization

  • If you store role information in Windows groups, consider using the WCF PrincipalPermissionAttribute class for role authorization
  • If you use ASP.NET roles, use the ASP.NET Role Manager for role authorization
  • If you use Windows groups for authorization, use the ASP.NET role provider with AspNetWindowsTokenRoleProvider
  • If you store role information in SQL Server, consider using the SQL Server role provider for role authorization
  • If you store role information in ADAM, use the Authorization Manager role provider
  • If you store role information in a custom store, create a custom authorization policy
  • If you need to authorize access to WCF operations, use declarative authorization
  • If you need to perform fine-grained authorization based on business logic, use imperative authorization

Bindings

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

Configuration Management

  • Use replay detection to protect against message replay attacks
  • If you host your service in a Windows service, expose a metadata exchange (mex) binding
  • If you don't want to expose your WSDL, turn off HttpGetEnabled and metadata exchange (mex)
  • Encrypt configuration sections that contain sensitive data

Exception Management

  • Use structured exception handling
  • Do not divulge exception details to clients in production
  • Use a fault contract to return error information to clients
  • Use a global exception handler to catch unhandled exceptions

Hosting

  • Run your service in a least-privileged account
  • Use IIS to host your service, unless you need to use a transport that IIS does not support

Impersonation/Delegation

  • Know the tradeoffs involved in impersonation
  • Know your impersonation options
  • Know your impersonation methods
  • Consider using programmatic instead of declarative impersonation
  • When impersonating programmatically, be sure to revert to the original context
  • When impersonating declaratively, only impersonate on the operations that require it
  • When you cannot do a Windows mapping, consider using the S4U feature for impersonation and delegation
  • If your WCF service cannot be trusted for delegation, consider using the LogonUser API
  • If you have to flow the original caller to the back-end services, use constrained delegation

Message Validation

  • If you need to validate parameters, use parameter inspectors
  • Use schemas with message inspectors to validate messages
  • Use regular expressions in schemas to validate format, range, or length
  • Implement the AfterReceiveRequest method to validate inbound messages on the service
  • Implement the BeforeSendReply method to validate outbound messages on the service
  • Implement the AfterReceiveReply method to validate inbound messages on the client
  • Implement the BeforeSendRequest method to validate outbound messages on the client
  • Validate operation parameters for length, range, format, and type
  • Do not rely on client-side validation
  • Avoid user-supplied file name and path input
  • Do not echo untrusted input

Message Security

  • If you need to support clients over the Internet, consider using message security
  • If there are intermediaries between the client and service, consider using message security
  • If you need to support selective message protection, use message security
  • If you need to support multiple transactions per session using secure conversation, use message security
  • Do not pass sensitive information in SOAP headers when using HTTP transport and message security
  • If you need to support interoperability, consider setting negotiateServiceCredentials to false
  • If you need to streamline certificate distribution to your clients, consider negotiating the service credentials
  • If you need to limit the clients that will consume your service, consider setting negotiateServiceCredentials to false

Transport Security

  • Use transport security when possible
  • If you need to support clients in an intranet, use transport security
  • If you need to support interoperability with non-WCF clients, use transport security
  • Use a hardware accelerator when using transport security

Proxy Considerations

  • Publish your WCF service metadata only when required
  • If you need to publish your WCF service metadata, publish it over the HTTPS protocol
  • If you need to publish your WCF service metadata, publish it using a secure binding
  • If you turn off mutual authentication, be aware of service spoofing

Sensitive Data

  • Avoid plain-text passwords or other sensitive data in configuration files
  • Use platform features to manage keys where possible
  • Protect sensitive data over the network
  • Do not cache sensitive data
  • Minimize exposure of secrets in memory
  • Be aware that basicHttpBinding will not protect sensitive data by default
  • Use appropriately sized keys

Deployment Considerations

  • Do not use temporary certificates in production
  • If you are using Kerberos authentication or delegation, create an SPN
  • Use IIS to host your WCF service wherever possible
  • Use a least-privileged account to run your WCF service
  • Protect sensitive data in your configuration files