Soudamini's blog

Key security features include:

 Auditing: Effective auditing and logging is the key to non-repudiation. Non-repudiationguarantees that a user cannot deny performing an operation or initiating a transaction.

Authentication: Authentication allows you to confidently identify the clients of your service. These might be end users, other services, processes, or computers. WCF supports mutual authentication, which identifies both the client and the service in tandem, to help in preventing man-in-the-middle attacks.

Authorization: Authorization determines what system resources and operations can be accessed by the authenticated user. This allows you to grant specific application and resource permissions for authenticated users.

Confidentiality: Confidentiality, also referred to as privacy, is the process of making sure that data remains private and confidential, and that it cannot be viewed by unauthorized users. Encryption is frequently used to enforce confidentiality. Privacy is a key concern, particularly for data / messages passed across networks.

Integrity: Integrity is the guarantee that data is protected from accidental or deliberate modification. Like privacy, integrity is a key concern, particularly for data / messages passed across networks. Integrity for data in transit is typically provided by using hashing techniques and message authentication codes.

The above fundamental security features are covered in the following WCF features:

Transfer security: Responsible for providing message confidentiality, data integrity, and authentication of communicating parties.

Authorization: Responsible for providing a framework for making authorization decisions.

Auditing: Responsible for logging security-related events to the audit log.

WCF provides access to these features through bindings and behavior configuration. Bindings control the security mode, client credential type, and other security settings. Service behaviors control impersonation levels, how client credentials are authenticated and authorized, and service credentials.

Transfer Security: After selecting a binding, we can decide which type of transfer security/security mode, to use for the WCF service. Security can be provided on the transport level or the message level. Each option has its own advantages and disadvantages. For instance, transport security secures the entire communication channel (e.g., by using SSL) and therefore only supports point-to-point communication over a single transport. Message security protects each message individually and therefore supports multipoint communication, multiple transports, or even partial message encryption if necessary. The different security modes are: None, Transport, Message, Both, Transport with message credential and Transport credential only (available only on basicHttpBinding).

When using transport security, the user credentials and claims are passed using the transport layer. In other words, user credentials are transport-dependent, which allows fewer authentication options compared to message security. Each transport protocol (TCP, IPC, MSMQ, or HTTP) has its own mechanism for passing credentials and handling message protection. The most common approach for this is to use Secure Sockets Layer (SSL) for encrypting and signing the contents of the packets sent over Secure HTTP (HTTPS). Transport security is used to provide point-to-point security between the two endpoints (service and client). If there are intermediary systems between the client and the service, each intermediate point must forward the message over a new SSL connection. In this case performance may be better. But it has limited options and largely dependent on security service provider such as NTLM or Kerberos.

When using message security, the user credentials and claims are encapsulated in every message using the WS-Security specification to secure messages. This option gives the most flexibility from an authentication perspective. It provides end-to-end security. Because message security directly encrypts and signs the message, having intermediaries does not break the security. It allows partial or selective message encryption and signing, thus improving overall application performance. Message security is transport-independent and can be used with any transport protocol. It supports a wide set of credentials and claims, including issue token, which enables federated security. The disadvantage is performance. The various protection levels available with message security are: None, Sign and EncryptAndSign.

Configuring the Protection Level

Example of using ProtectionLevel.Sign at the Service Contract and operation contract level:

[ServiceContract(ProtectionLevel=ProtectionLevel.Sign]

public interface IService{

            string GetData(int value);}

[OperationContract(ProtectionLevel=ProtectionLevel.Sign]

string GetData(int value);

Service Credentials Negotiation

In addition to client authentication, a WCF service needs to provide its credentials to the clients in order to support mutual authentication. Service credentials should be negotiated for mutual authentication. The message security supports this by default. If message security is configured not to negotiate service credentials then the client and service needs to be in the same domain when using Windows authentication. The service certificate should be accessible to the client when using non-Windows authentication such as username or certificate authentication. When using transport security, the service credentials are always negotiated and there is no control over configuration.

Secure Session

A secure session is a message security feature that reduces the overhead of one-off key exchange and validation. By default, secure sessions are enabled for message security. A secure session can be established between the client and server by creating a security context token. All subsequent message exchanges will use this token, thereby creating a secure session. By default, the lifetime for this token is 15 minutes when issued, and the token is reissued if it is required beyond 15 minutes. Therefore, when multiple messages are exchanged in a 15-minute lifespan, both the messages will be secured by using the same security context token, so security in this case will be weaker. To overcome this vulnerability, you can use derived keys, where two keys are derived from a symmetric key. You can use one of the keys to sign the Simple Object Access Protocol (SOAP) message and the other to encrypt various parts of the SOAP message.

Authentication

The WCF authentication options available depend on the transfer security mode used. The choice of binding will also play a role in the authentication options because not all transport or message user credentials are supported in every binding.

Transport Security Mode Authentication Options

The follow authentication options are available when using transport security mode:

• None: The WCF service does not authenticate the callers. This is not the recommended.
• Basic: This option is available with the HTTP protocol only. The client is authenticated using the username and password against Active Directory. The client credentials are transported using the Base64 encode string, which is literally like a clear string and therefore is not the most secure option. The service is authenticated by the SSL certificate used for secure communication.
• NTLM: This option is available with the HTTP protocol only. The client is authenticated using a challenge-response scheme against Windows accounts. The NTLM option is well suited for a workgroup environment. NTLM authentication is more secure than either Digest or Basic authentication. The service is authenticated using the Windows credentials of the process identity or using an SSL certificate.
• Windows: The Windows option tells the WCF service to use Kerberos when in a domain, or NTLM when deployed in a workgroup environment. This option uses a Windows token presented by the caller to authenticate against Active Directory. This is the most secure option compared to Basic, Digest, or NTLM authentication. The service is authenticated using the Windows credentials of the process identity or an SSL certificate if you are using the HTTP protocol.
• Certificate:  Here the caller presents an X.509 client certificate that the WCF service either validates with peer trust or trusts based on the issuer of the certificate. This option should be used when Windows authentication is not possible e.g. business-to-business (B2B) scenarios. The service is authenticated with the service certificate or by using an SSL certificate if you are using the HTTP protocol.

Message Security Mode Authentication Options

The follow authentication options are available when using message security mode:

• None: In this case the WCF service does not authenticate callers. This is not the recommended option from a security perspective.
• Windows: Here the WCF service uses Kerberos when in a domain, or NTLM when deployed in a workgroup environment. This option uses the Windows token presented by the caller in order to authenticate against the Active Directory. The service is authenticated using the Windows credentials of the process identity.
• Username: IN this case, the caller provides the username and password to the service. The service can authenticate against Windows, use membership providers such as SqlMembershipProvider, or use a custom validator to validate against the custom store. This option should be used only when Windows authentication is not possible. The service is authenticated with a service certificate.
• Certificate. When using this option, the caller presents an X.509 client certificate; the WCF service looks up the certificate information on the host side and either validates it (peer trust) or trusts the issuer (chain trust) of the client certificate. This option should be used when Windows authentication is not possible, or in B2B scenarios. Service is authenticated with a service certificate.
• Issue token: When using this option, the client and service depend on a secure token service (STS) to issue tokens that the client and service trusts. Microsoft Windows Identity Foundation is a typical example of an STS.

Authorization in WCF

WCF supports the following three basic authorization approaches:

• Role-based: Access to WCF operations is secured based on the role membership of the caller. The role store can be Windows groups(If WCF services and clients are deployed in the same Windows domain), ASP.NET roles (if system have fine-grained roles requirements, or if the users cannot be mapped to Windows domain accounts), or a custom role store(your role information is stored in a custom store such as a SQL Server database, create a custom authorization policy to authorize your users.).  The ASP.NET roles can be implemented as below.
  • SqlRoleProvider: If your role information is stored in a Microsoft SQL Server database, consider using the SqlRoleProvider for role-based authorization.
  • WindowsTokenRoleProvider: If your roles are Window groups, and you want to leverage the Role Manager feature as a consistent way to check the role membership of your users, regardless of the underlying data store, consider using the WindowsTokenRoleProvider for role-based authorization.
  • AuthorizationStoreRoleProvider: If your role information is stored using the AzMan policy store in an XML file, in Active Directory, or in Active Directory Application Mode (ADAM), consider using the AuthorizationStoreRoleProvider for role-based authorization.
  • Identity-based. WCF supports an Identity Model feature, which is an extension to role based authorization. Identity Model enables to manage claims and policies to authorize clients.
  • Resource-based: Individual resources are secured using Windows access control lists (ACLs). The WCF service impersonates the caller prior to accessing resources, which allows the operating system to perform standard access checks. All resource access is performed using the original caller’s security context. The resources can be multiple databases, database tables, external applications and web services. If resources are remote, delegation is used. The two most commonly used resource-based security models are:
    •  The trusted subsystem model: The steps include authenticate users, map users to roles, authorize based on role membership, access the downstream resource manager using a single or multiple fixed trusted identities.
    •  The impersonation/delegation model

It is recommended to implement a custom role provider, using the Role Manager feature, for custom role store rather than using the custom roles option.

Imperative Authorization

Imperative authorization supports fine-grained authorization choices based on business logic. Imperative role-based authorization is written and processed at run time. Imperative security is useful when the resource to be accessed or action to be performed is not known until run time, or when you require finer-grained access control beyond the level of a code method.

Example

The following is an example of an Imperative check using the ASP.NET role provider:

if (Roles.IsUserInRole(@”accounting”))

{

//authorized

}

else

{

//authorization failed

}

Declarative Authorization

Declarative authorization can be added to application code at design time by specifying required access for a particular method or class declared as an attribute on the operation. Declarative role-based authorization is best for authorizing access to WCF at the operation level. Because attribute metadata is discoverable using reflection, it is easier to track the security principals that are allowed to access each method. Declarative authorization checks will work if you are using the ASP.NET role provider or Windows groups.

Example

The following code example shows how to use the PrinciplePermission attribute to perform declarative authorization:

[PrincipalPermission(SecurityAction.Demand, Role = "accounting")]

public double Add(double a, double b)

{

return a + b;

}

Impersonation / Delegation

Impersonation is a technique that WCF services use to assume the original caller’s identity in order to authorize access to service resources (such as files or database tables). Service resources can be local to the service machine, or remote to the service machine. Impersonation is used to access resources on the same machine as the service, while delegation is used to access resources that are remote to the service. Delegation allows using an impersonation token to access network resources.

Impersonation at the service side can be controlled using the ImpersonationOption enumeration for the OperationBehavior attribute. The available values for the enumeration are:

• NotAllowed: Impersonation is not performed in a particular operation.
• Allowed: Impersonation is performed if the original Windows token is available and the service is configured to impersonate on all operations using ImpersonateCallerForAllOperations in ServiceAuthorizationBehavior.
• Required. Impersonation is performed; the Windows identity token is required to be available.

Imepersonation at client side can be controlled by setting the AllowedImpersonationLevel property of windows credentials to the following TokenImpersonationLevel options.

• None: The WCF service cannot authenticate or impersonate the user.
• Anonymous: The WCF service authenticates clients as anonymous, but cannot obtain information for identification or impersonation.
• Identification: The WCF service can authenticate clients and get information for identification, but cannot impersonate the clients. This is the default value.
• Impersonation: The WCF service can authenticate, get information for identification, and impersonate clients on local systems. Delegation: The WCF service can authenticate, get information for identification, and impersonate clients on local as well as remote systems.

Auditing

WCFServiceAuditing lets user to detect an attack that has occurred or is in progress and can help debug security-related problems. Auditing can be enabled via configuration by using the ServiceSecurityAuditBehavior element. The event log location for auditing the events can be specified in the auditLogLocation attribute.

Identities in WCF

While designing authentication and authorization strategies, the following identity types are considered:

• Process identity: This is the identity of the process hosting the WCF service. When the WCF service is hosted in Internet Information Services (IIS), it typically is NETWORK SERVICE by default. This means that the machine account credentials of the service host are presented to downstream resources. The process identity is important because it identifies what Windows resources and back-end the service can access, when the WCF service is not impersonating the original caller. If a certificate is used to protect the transport, the process identity also needs access to the certificate’s private keys in order to provide for message security or transport security with netTcpBinding.
• Security principal. The executing thread includes a security principal that contains the user identity and associated roles. The roles can be Windows roles if the principal is a Windows Principal; an ASP.NET role if it is a role Principal; or a custom role if it is a generic Principal. To be able to authorize – either with the Roles.IsinRole call, with IPrincipals.IsInRole, or with declarative authorization checks – a security principal must be present in the thread executing the WCF business logic. If a custom authentication is used in WCF, the security principals must be set in a class that derives from IAuthorizationPolicy, and this custom authorization policy must be configured in WCF.
• ServiceSecurityContext. This identity type, available in the WCF run time, contains all of the security-related objects available in the WCF context. These objects are the user identity and authorization context and polices. The service security context is available on both the service and the client side. In the authorization context, you can extract the claim set associated with a security token, whether it is a certificate, issue token, username, or Windows token. To get the service security context on the client side, you need to use the operation context instead.

Reference : WCF Security guide from patterns & practices