WCF Security Guidelines

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