For this week's release in our patterns & practices WCF Security Guidance project, we released our first version of our WCF 3.5 Security Guidelines.  Each guideline is a nugget of what to do, why, and how.  The goal of the guideline format is to take a lot of information, compress it down, and turn insight into action.

The downside is that it's tough to create prescriptive guidelines that are generic enough to be reusable, but specific enough to be helpful.  The upside is that customers find the guidelines help them cut through a lot of information and take action.  We contextualize the guidelines as much as we can, but ultimately you're in the best position to do the pattern matching to find which guidelines are relevant for your scenarios, and how you need to tailor them.

Here's a snapshot of the guidelines, but you can see our security guidelines explained at our WCF Security Guidance project site.

Categories
Our WCF Security guidelines are organized using the following buckets:

• Auditing and Logging
• Authentication
• Authorization
• Binding
• Configuration Management
• Exception Management
• Hosting
• Impersonation and Delegation
• Input/Data Validation
• Proxy Considerations
• Deployment considerations 

Auditing and Logging

• Use WCF auditing to audit your service
• If non-repudiation is important, consider setting SuppressAuditFailure property to false
• Use message logging to log operations on your service
• Instrument for user management events
• Instrument for significant business operations
• Protect log files from unauthorized access
• Do not log sensitive information

Authentication

• Know your authentication options
• Use Windows Authentication when you can
• If you support non-WCF clients using windows authentication and message security, consider using the Kerberos direct option
• If your users are in AD, but you can’t use windows authentication, consider using username authentication
• If your clients have certificates, consider using client certificate authentication
• If you need to streamline certificate distribution to your clients for message encryption, consider using the negotiate credentials option
• If your users are in a custom store, consider using username authentication with a custom validator
• If your users are in a SQL membership store, use the SQL Membership Provider
• If your partner applications need to be authenticated when calling WCF services, use client certificate authentication.
• If you are using username authentication, use SQL Server Membership Provider instead of custom authentication
• If you need to support intermediaries and a variety of transports between client and service, use message security to protect credentials
• If you are using username 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 Windows Forms to connect to WCF, do not cache credentials

Authorization

• If you use ASP.NET roles, use the ASP.NET Role Provider
• If you use windows groups for authorization, use ASP.NET Role Provider with AspNetWindowsTokenRoleProvider
• If you store role information in SQL, consider using the SQL Server Role Provider for roles authorization
• If you store role information in Windows Groups, consider using the WCF PrincipalPermissionAttribute class for roles authorization
• 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

Binding

• 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 remote WCF clients within an intranet, consider using netTcpBinding.
• If you need to support local WCF clients, 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.

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)
• Manage bindings and endpoints in config not code
• Associate names with the service configuration when you create service behavior, endpoint behavior, and binding configuration
• 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

• If you are hosting your service in a Windows Service, use a least privileged custom domain account
• If you are hosting your service in IIS, use a least privileged service account
• Use IIS to host your service unless you need to use a transport that IIS does not support

Impersonation and Delegation

• Know the impersonation options
• If you have to flow the original caller, use constrained delegation
• Consider LogonUser when you need to impersonate but you don’t have trusted delegation
• Consider S4U when you need a Windows token and you don’t have the original caller’s credentials
• Use programmatic impersonation to impersonate based on business logic
• When impersonating programmatically be sure to revert to original context
• Only impersonate on operations that require it
• Use OperationBehavior to impersonate declaratively

Input/Data Validation

• If you need to validate parameters, use parameter inspectors
• If your service has operations that accept message or data contracts, use schemas to validate your messages
• If you need to do schema validation, use message inspectors
• Validate operation parameters for length, range, format and type
• Validate parameter input on the server
• Validate service responses on the client
• Do not rely on client-side validation
• Avoid user-supplied file name and path input
• Do not echo untrusted input

Proxy Considerations

• Publish your metadata over HTTPS to protect your clients from proxy spoofing
• If you turn off mutual authentication, be aware of service spoofing

Deployment considerations

• Do not use temporary certificates in production
• If you are using a custom domain account in the identity pool for your WCF application, create an SPN for Kerberos to authenticate the client.
• If you are using a custom service account and need to use trusted for delegation, create an SPN
• If you are hosting your service in a Windows Service, using a custom domain identity, and ASP.NET needs to use constrained trusted for delegation when calling the service, create an SPN
• Use IIS to host your service unless you need to use a transport that IIS does not support
• Use a least privileged account to run your WCF service
• Protect sensitive data in your configuration files

My Related Posts

• patterns & practices WCF Security Guidance: Updated Application Scenarios
• patterns & practices WCF Security Application Scenarios
• patterns & practices WCF Security Guidance Now Available