Difference between revisions of "WCF Security Best Practices"

Latest revision as of 04:17, 16 May 2008

From WCF 3.5 Security Guidelines
(@Codeplex by J.D. Meier , Jason Taylor , Prashant Bansode , Carlos Farre, Madhu Sundararajan, Steve Gregersen.)

Design Considerations

• Design your service as a wrapper
• If you are coming from ASMX then use basicHttpBinding to support your existing clients
• If you are coming from DCOM then, use netTcpBinding
• If your clients are deployed within intranet then choose transport security
• If your clients are deployed over the internet then choose message security
• Know your Authentication options
• Know your binding options
• If you need to Interop with non MS clients, use basicHttpBinding or wsHttpBinding
• If your non-MS clients understand WS stack, use wsHttpBinding

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 you are using username authentication, use Membership Provider instead of custom authentication
• If your users are in a SQL membership store, use the SQL Membership Provider
• If your users are in a custom store, consider using username 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 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 store role information in Windows Groups, consider using the WCF PrincipalPermissionAttribute class for roles 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 ADAM, use the Authorization Store Role Provider 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