WCF Security

Overview

Services and service consumers are often on opposite sides of trust boundaries. A trust boundary is a physical or virtual boundary within which actual levels of trust can vary. A trust boundary can be an application process, a machine, or even the Internet itself. When SOAP messages flow through a trust boundary, they may need to be transmitted between nodes, through firewalls, across intermediaries, and so on. Each of these points of contact can introduce message security threats, such as breach of integrity, breach of confidentiality, breach of authentication, and breach of authorization.

A service may be accessed by a service consumer over the Internet or via a local intranet. Cross-service Internet communication typically relies on the exchange of username and password credentials to identify users. On an intranet, Windows security using Active Directory over TCP is common for authentication. Certificates are also frequently used to identify service consumers in both environments.

WCF bindings support confidentiality, integrity, and authentication. It is important to understand that WCF does not automatically provide protection against threats. Attacks, such as SQL injection and XML parser attacks will generally require attention to service logic and general infrastructure configuration.

Security controls work consistently across bindings. If a binding changes, security settings will simply be carried forward. WCF supports both transport-layer security and message-layer security.

While most of the security detail is incorporated into the platform and preconfigured, two factors need to be considered when designing WCF services and service compositions:

• security mode
• credential type

The security mode is based on credentials. Credentials provide claims made by a service consumer to the service. Claims are packaged in security tokens that are contained in messages that can travel over process and machine boundaries. WCF authenticates and authorizes these claims.
Supported credential types include:

• Username
• Kerberos
• X509

Let’s talk more about security modes and how they process these types of credentials.

Security Modes

Credentials can be transmitted using either the transport security mode (transport-layer security) or the message security mode (message-layer security.

The transport security mode relies on the use of the Secure Sockets Layer (SSL) technology to encrypt the transport. This provides performance benefits and simplified security architecture. The downside is that it does not support newer and richer types of credentials, such as SAML tokens, and is primarily suitable for point-to-point communication, as opposed to communication that involves intermediaries.

The message security mode enables claims to be secured within the message. It is extensible in support of different credential types (such as SAML) and ensures that protected content cannot be read or tampered with by intermediaries along a given message path. The downside is an increase in runtime processing requirements.

WCF also supports mixed mode security, which allows integrity and confidentiality requirements to be addressed by SSL, while authentication and authorization requirements are satisfied within the message.

none: no security is provided at the transport or message layers

transport: transport-layer security is used, meaning HTTPS is employed to secure the integrity and confidentiality of the transport

message: message-layer security is used for integrity, confidentiality, and authentication

mixed mode: a combination of transport security and message security modes can be used

Note that when the transport security mode is chosen, authentication requirements can be addressed using the options listed below

none: no authentication credentials are required by the service (all service consumers access the service anonymously and are granted complete access)

basic: the service consumer provides username and password credentials to the service in plain text (because the transport has been secured, sending username and password as plain text is not considered a threat)

digest: the service consumer provides username and password credentials to the service (the password is encrypted before it is sent)

windows: the service uses Windows authentication (Kerberos is the default authentication mechanism and the user is authenticated against Active Directory)

certificate: the service consumer provides an X509 certificate to the service

Security industry standards provide the preferred means of establishing security architectures in support of inherent interoperability among services. These standards include WS-Trust, WS-SecureConversation,
WS-SecurityPolicy, WS-Security and the WS-I Basic Security Profile.

A service does not need to be constrained by a single binding or security setting. The same service can be exposed over multiple bindings. For example, one service may be exposed via the Internet using a simple WS-I Basic Security Profile binding over HTTPS, as well as over TCP for local consumers
in the same domain using Windows authentication.

Authorization

WCF provides several extensibility hooks that allow you to plug in the authorization policy of your choice and check the validity of the claims. Supported authorization plug-ins include:

• ASP.NET membership and role providers
• Authorization Manager
• custom-developed code
• .NET role-based security infrastructure

For example, using Thread.CurrentPrincipal is the standard way to access a service consumer’s identity in .NET. If the type of credentials is set to “Windows,” then Thread.CurrentPrincipal will point to WindowsPrincipal and you can determine if the consumer belongs to a valid role by using WindowsPrincipal.IsInRole, as follows:

IPrincipal user = Thread.CurrentPrincipal;
if (user.IsInRole(@"DomainName\contributors "))
{
... allow users to contribute ...
}

Federated Identity

In WCF, federated identity represents the ability to enable an organization to accept and process
identities issued by other organizations. WCF allows different partner organizations to have the
same single sign-on experience, even when they use services that are external to their domain. Federation automates the existing trust relationship between partners, which, in turn, tends to reduce
potential mistakes, latency, and maintenance costs.