Fundamentals of WCF Security (Part Two)

<<Part One>>

Fundamental Security Concepts (Continued):

The below are some of the available security settings in Windows Communication Foundation (WCF)

Security Settings in WCF:

• Security mode
• Protection level
• Client and service credentials
• Impersonation
• Credential negotiation
• Secure sessions
• Authentication and authorization behaviors

The first step to securing a WCF service is defining the “Security Policy”. Once you have established requirements for Authentication, Authorization, and Message protection it is a matter of service configuration to enforce it. In WCF the binding selection process will influence/control the available configuration options for the “Service Security Policy”. When you expose a service endpoint you select a binding that represents the appropriate communication protocol and message encoding format.
The below are the standard sets of bindings that can satisfy the respective protocol and encoding choices:

• NetTcpBinding
  • Is the right choice for binary TCP communications that cross machine boundaries
• BasicHttpBinding
  • Is the right choice for HTTP communications that must support legacy web service protocols.
• WSHttpBinding or WSFederationHttpBinding
  • Is the right choice for Web services that can leverage a richer set of standards including those for secure communications (the latter is used for federated security scenarios).

Beyond bindings, behaviors also provide information about client and service credentials, and affect how authorization is handled. You can configure bindings and behaviors declaratively or through the runtime object model.
Each binding has a default set of security settings defined. Consider the following service endpoint that supports NetTcpBinding.

<system.serviceModel>

<services>

<service name="HelloIndigo.HelloIndigoService" >

<endpoint contract="HelloIndigo.IHelloIndigoService" binding="netTcpBinding" />

</service>

</services>

</system.serviceModel>

• Is secure by default.
• Specifically, callers must provide “Windows credentials” for authentication and all message packets are “Signed and Encrypted” over TCP protocol.
• Look at the expanded binding configuration illustrating these default settings

<netTcpBinding>

<binding name="netTcp">

<security mode="Transport" >

<transport clientCredentialType="Windows"/>

</security>

</binding>

</netTcpBinding>

• When the security mode is set to “Message security”, you can customize the default security settings for NetTcpBinding by configuring different values for “clientCredentialType” or “algorithm suite”

Each of the standard WCF bindings supports only relevant security options for their typical usage.

Security Modes :

Below are the 5 possible “Security Modes” across all “Service Bindings”.

• None - Turns security off.
• Transport - Uses “Transport security” for mutual authentication and message protection.
• Message - Uses “Message security” for mutual authentication and message protection.
• Both - Allows you to supply settings for transport and message-level security (only MSMQ supports this).
• TransportWithMessageCredential - Credentials are passed with the message and message protection and server authentication are provided by the transport layer.
• TransportCredentialOnly - Client credentials are passed with the transport layer and no message protection is applied.

You can turn off security completely, or allocate authentication and message protection between transport and message-level security. Each transport protocol (TCP, IPC, MSMQ, or HTTP) has their own mechanism for passing credentials and handling message protection. Message security supports passing credentials as part of the SOAP message using interoperable standards, and also makes it possible to protect the message independent of transport all the way through to the ultimate message receiver. Transport message protection is only good from point to point.
To control the security mode used for a particular binding, set the mode property for the binding’s <security> section. For Transport or modes that use transport security, the <transport> section should be expanded. For Message mode, settings are supplied in the expanded <message> section.
Transport Security:

<netTcpBinding>

<binding name="netTcp">

<security mode="Transport" >

<transport clientCredentialType="Windows"/>

</security>

</binding>

</netTcpBinding>

Message Security:

<wsHttpBinding>

<binding name="wsHttpBinding">

<security mode="Message" >

<message clientCredentialType="UserName"/>

</security>

</binding>

</wsHttpBinding>

Mixed Security:

<basicHttpBinding>

<binding name="basicHttpBinding">

<security mode="TransportWithMessageCredential" >

</transport>

<message clientCredentialType="UserName"/>

</security>

</binding>

</basicHttpBinding>

Client Credential Type:

• The choice of “Client Credential Type” depends on the “Security Mode” used.
• “Windows Credential” or “Certificate” is used for “Transport Security”
• The below are the list of client credential types for “Message Security”:
  • None
  • Windows
  • UserName
  • Certificate
  • Issued Tokens (including CardSpace claims) or custom tokens
• Selections vary for binding configurations
• “BasicHttpBinding” supports “Username and Certificate Credentials” only.

Example Security Settings for the BasicHttpBinding Binding:

• It supports only “UserName” and “Certificate” credentials since it is intended to be interoperable with “Basic Security Profile” per WS-I.
• The below code snippet illustrates how to select a “clientCredentialType” for message security.

<basicHttpBinding>

<binding name="basicHttp">

<security mode="TransportWithMessageCredential" >

<message clientCredentialType="Certificate"/>

</security>

</binding>

</ basicHttpBinding >

• Note: The choice of “Credential Type” affects other Configuration settings for the service. (Ex Username credential require either a “Transport message” protection or “Service Certificate” to protect the exchange”.

Protection Level:

• By default, all secure WCF bindings will encrypt and sign messages.
• It cannot be disabled for “Transport Security” (Cannot throttle SSL settings)

<netTcpBinding>

<binding name="signOnly">

<security>

<transport protectionLevel="Sign"/>

</security>

</binding>

</netTcpBinding>

• It can be disabled for “Message Security” for debugging purposes or when an alternate method of protection is used such as IPSec.
• “Protection-level settings” are controlled by the contract.
• It can be specified for all operations in the service contract using “ServiceContractAttribute”
• The following example illustrates disabling encryption for message security.

[ServiceContract(Name="HelloIndigoContract", Namespace="http://www.example.com/examples", ProtectionLevel=ProtectionLevel.Sign)]
public interface IHelloIndigoService
{
string HelloIndigo(string inputString);
}

• For more granular control, you can also indicate message protection per operation using the “OperationContractAttribute”.
[ServiceContract(Name="HelloIndigoContract",
Namespace= ”http://www.example.com/examples”]
public interface IHelloIndigoService
{
[OperationContract(ProtectionLevel= ProtectionLevel.Sign)]
string HelloIndigo(string inputString);
}

Protection Level Options:

• None: Disables message protection
• Sign: Indicates message should be signed but not encrypted
• EncryptAndSign: Provides full message protection and is the default behavior.
• The ProtectionLevel property serves a dual role.
• First, it specifies the minimum requirements for message protection.
  • If the property is not specified, the default behavior is to encrypt and sign, but enforce those settings on the binding.
  • Messages that don’t meet the requirement will be rejected for not satisfying the security policy
• The second role is to control how message-level protection is applied

Algorithm Suite:

• This suite defines the algorithms and key lengths for cryptographic operations like “Key Signatures”, ”Encryption” and “Key Wrap”.
• Each Binding uses “Basic 256” as the default Algorithm suite for “Message Level Security”.
• Algorithm suites are described in the WS-SecurityPolicy specification, and can be applied by setting the algorithm attribute of the <message> section.

<wsHttpBinding>

<binding name="wsHttp">

<security mode="Message" >

<message clientCredentialType="UserName" algorithmSuite="TripleDes" />

</security>

</binding>

</wsHttpBinding>

Client and Service Credentials:

Client Credentials:

• Credential options:
  • Windows
  • Username and password
  • X.509 certificates
  • Issued SAML tokens (including CardSpace claims) or custom tokens
• Selections vary for binding configurations
• Provide proxy with credentials

Service Credentials:

• Credential options:
  • Windows
  • X.509 certificates
• When clients use Windows credentials, so does the service
• When clients use non-Windows credentials, service must provide a certificate
  • Supplied by transport (SSL) or by associated service behavior

Impersonation:

Using the OperationBehaviorAttribute you can apply impersonation rules per operation by setting the Impersonation property to one of the following:

• ImpersonationOption.NotAllowed - The caller will not be impersonated.
• ImpersonationOption.Allowed - The caller will be impersonated if a Windows credential is provided.
• ImpersonationOption.Required- The caller will be impersonated and a Windows credential must be provided to support this.

This behavior is applied to service operations.
[OperationBehavior(Impersonation = ImpersonationOption.Allowed)]
public string DoSomething()
{
...
}

You can also set this for all operations by declaratively configuring the impersonateCallerForAllOperations attribute for the service authorization behavior.

<behaviors>

<serviceBehaviors>

<behavior name="serviceBehavior" >

<serviceAuthorization impersonateCallerForAllOperations="false"/>

</behavior>

</serviceBehaviors>

</behaviors>

Clients can also control impersonation, to prevent services from using their identity to access resources. Windows credentials have an AllowedImpersonationLevel property that can be set to one of the following:

• TokenImpersonationLevel.None
• TokenImpersonationLevel.Anonymous
• TokenImpersonationLevel.Identification
• TokenImpersonationLevel.Impersonate
• TokenImpersonationLevel.Delegate

None and Anonymous protect the caller’s identity but aren’t useful for authentication. Identify is the default and preferred setting since it allows services to identify the caller but disallows impersonation. Impersonate and Delegate will allow impersonation across one machine, or delegation with a Kerberos ticket, respectively.
You set the value on the proxy as follows:

localhost.HelloIndigoServiceClient proxy = new Client.localhost.HelloIndigoServiceClient();
…
proxy.ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Identification;

Service Credentials and Negotiation:

• Services must provide credentials to the caller to support “Mutual Authentication” and “Message Protection”
• When the “Transport Security” is used Service Credentials are negotiated through the “Transport Protocol”.
• When clients use Windows credentials, so does the service
• When clients use non-Windows credentials, service must provide a certificate
• Service credentials for message security can also be negotiated when Windows credentials are used; otherwise a service certificate must be specified in the <behaviors> section under <serviceCredentials> section.

<behaviors>

<serviceBehaviors>

<behavior name="serviceBehavior">

<serviceCredentials>

<serviceCertificate findValue="RPKey" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName" />

</serviceCredentials>

</behavior>

</behaviors>

• In the above case the caller must have access to the public key portion of the service certificate to encrypt messages sent to the service. This can be specified out of band, or negotiated with an initial handshake
• The default behavior for message security supports negotiation
• The service is dynamically asked for the correct token before any messages are exchanged.
• For Windows client credentials SPNego protocol is used and for UserName, Certificate or Anonymous credentials, TLSNego protocol is used.
• Today these are not interoperable protocols, so it may be desirable to disable this negotiation
• You can set negotiateServiceCredential to false in the <message> section to disable it

<wsHttpBinding>

<binding name="wsHttp">

<security mode="Message">

<message clientCredentialType="UserName" negotiateServiceCredential="false"/>

</security>

</binding>

</wsHttpBinding>

• When you generate a service proxy with configuration settings for the client (using svcutil.exe) an encoded version of the public certificate is supplied in the <identity> section to handle this case like below.

<client>

<endpoint address="http://localhost:8000/HelloIndigo" binding="wsHttpBinding" bindingConfiguration="wsHttp" contract="Client.localhost.HelloIndigoContract" name="WSHttpBinding_HelloIndigoContract">

<identity>

<certificate encodedvalue="AwAAAAEAAAAUAAAAreiGqilku9hngWEQL1g+ … oBd0vDwZaqjy47g0jFV9pF0VHhoVbTtOA==">

</identity>

</endpoint>

</client>

• It is also possible to install the public key of the service in the client certificate store and retrieve it from there at run time.

Secure Sessions:

• Another feature of message security is the ability to establish a secure session to reduce the overhead of “One-off key exchange” and “Validation”. By default, secure sessions are enabled for message security. A “Security Context Token (SCT)” is generated through an initial exchange between caller and service. This token is used to authorize and secure subsequent message exchanges.
• If the caller plans to make several calls to a service, secure sessions are more efficient. For a single call, however, you can disable this feature by setting establishSecurityContext to false.

<wsHttpBinding>

<binding name="wsHttp">

<security mode="Message">

<message clientCredentialType="UserName" establishSecurityContext="false"/>

</security>

</binding>

</wsHttpBinding>

Authentication, Authorization, and Identities:

• “Mutual authentication” is performed based on the supplied client and service credentials.
• “Message protection” is applied according to “Transport” or “Message” security configuration-which normally means that messages are both signed and encrypted.
• “Token Authentication”, “Runtime identities”, “Security Principals” and “Authorization Policies” also play an important role in the WCF security.
• Access to resources during a service operation is influenced by three keyelements:
  • Process Identity:
    • “Service operations” are executed under the process identity of the service host
    • For ASP.NET hosts this is usually the “ASP.NET account”, and for self-hosting it may be a different service account
    • This “Process identity” is the Windows account that governs what the service code can do at run time when attempting to access protected resources such as the database, registry or file system.
  • Security Principal:
    • If you are familiar with traditional .NET role-based security, there is a “Security Principal” attached to each executing thread.
    • That “Security Principal” holds the “Caller’s Identity”, which may or may not be tied with the “Windows account and roles”.
    • Roles govern which operations can be executed by the “Authenticated User” when the traditional “Role Based Security” is applied.
  • ServiceSecurityContext:
    • Provides run time access to other relevant information about the security context for a “Service Operation”.
    • The “ServiceSecurityContext” is a run time type that includes:
      1. Identities
      2. Set of claims
      3. Authorization Policies
    • This information can be used to apply a more fine-grained security strategy specifically for services

Relationship of security elements:

• Process Identity is common.
• Each operation is executed on a request thread that contains a unique “Security Principal” and “Security Context”
• Operations are executed within a security context that includes a set of claims and an identity

Claims-Based Identity Model:

• The identity model in WCF supports a rich, claims-based approach to authorization.
• “Claim” describes an individual right or action applicable to a particular resource authorization.
• Claims are generated from security tokens.
• “Security tokens” are abstractions of credentials that are passed in the security headers of a message and validated against the security policy
• When security tokens are validated and processed at the service, claims are extracted and placed into the security context for the operation being executed
• Ultimately, a “claimset” is attached to the ServiceSecurityContext and available for any custom authorization code involved in the execution of the operation

Role-Based Authorization:

• Is still alive and useful for controlling access to service operations and business classes used downstream.
• The identity of the caller is attached to the executing request thread in the form of a security principal, accessible through the “CurrentPrincipal Property”.
• The security principal is a wrapper for an identity-its type directly related to the token type received. For example, it could be a “WindowsIdentity”,” X509Identity”, “GenericIdentity”, or a “Custom type” that implements “System.Security.Principal.IIdentity”. The identity is created during authentication.

Custom Authorization Policies:
You can create custom authorization policies for your WCF services. Custom Authorization Policies are types that implement the IAuthorizationPolicy interface from the System.IdentityModel.Policy namespace.
Below are a few reasons to create a custom authorization policy:

• When the service requires SAML tokens as the client credential type the claims are not authenticated against any existing role provider. A custom authorization policy can inspect these claims and initialize the security context accordingly.
• A service may replace traditional role-based security with claims-based security. An authorization policy can be used to normalize the set of claims received from different tokens into a common set of claims used for claims-based security.
• Services that use a custom role provider must provide an authorization policy to create an IPrincipal for the security context. Without it, authorization will fail.

Applied WCF Security: Intranet Applications

• Internal applications that run on the intranet (and share the same Windows domain as the service) can generally take advantage of a faster transfer protocol like TCP.
• In terms of security settings, the following may apply:
  • Windows client credentials are used for client authentication.
  • Authentication and authorization use default Windows membership and role providers.
  • Messages are encrypted and signed by the transport layer.
  • The service will be self-hosted or hosted in the Windows Activation Service (WAS) for TCP access.
  • The service implements role-based permission demands on protected operations.
  • The service usually rejects impersonation in favor of trusted subsystem model

Applied WCF Security: Internet Applications

• When remote clients are not part of the Windows domain, they use Internet protocols to access services (HTTP or HTTPS).
• To expose an endpoint that supports earlier Web service standards, WS-IBasic profile is the typical baseline
• So, the requirements of the service might be:
• An SSL connection is used to identify the service and to protect message transfer over HTTPS
• UserName credentials are used for client authentication.
• Authentication and authorization use the built-in ASP.NET membership and provider model.
• Services are hosted in IIS with ASP.NET integration.
• A service certificate is supplied for message security and service authentication

Applied WCF Security: Business partner applications

• A business partner accessing your services over the Internet may require a different approach to authentication and authorization.
• Consider the below requirements:
• A service certificate is supplied to identify the service and protect messagesduring transfer.
• Certificates are used to uniquely identify partners
• Certificates are authenticated using the default certificate validation process
• Certificates are authorized by placing the corresponding public key of each partner in the TrustedPeople folder for the LocalMachine certificate store
• The client configuration generated by svcutil.exe doesn’t include information about the location of the client certificate
• You must make a modification to the configuration on the client to add the following behavior and associate it to the client endpoint.

<behaviors>

<endpointBehaviors>

<behavior name="clientBehavior">

<clientCredentials>

<clientCertificate findValue="SubjectKey" storeLocation="CurrentUser" storeName="My" x509FindType="FindBySubjectName" />

</clientCredentials>

</behavior>

</endpointBehaviors>

</behaviors>

• Certificate credentials can also be useful for services authenticating across tiers behind the firewall

Summary:

WCF Services expose a collection of Endpoints where each Endpoint is a portal for communicating with the world. Each Endpoint has an Address, a Binding, and a Contract (ABC). The Address is where the Endpoint resides, the Binding is how the Endpoint communicates, and the Contract is what the Endpoint communicates.

• WCF provides granular control over security through bindings and behaviors.
• Common scenarios include intranet, business partner exchanges and Internet applications.
• The environment is highly extensible.
• WCF also supports rich federated and claims-based security models

Resources:

What Is Windows Communication Foundation?
http://msdn.microsoft.com/en-us/library/ms731082.aspx
Security Architecture:
http://msdn.microsoft.com/en-us/library/ms788756.aspx
Windows Communication Foundation Architecture Overview:
http://msdn.microsoft.com/en-us/library/aa480210.aspx
Fundamental Windows Communication Foundation Concepts:
http://msdn.microsoft.com/en-us/library/ms731079.aspx
Windows Communication Foundation Architecture:
http://msdn.microsoft.com/en-us/library/ms733128.aspx
WCF Security Fundamentals: http://www.dasblonde.net/downloads/sessions/WCFSecurityFundamentals.pdf
Fundamentals of WCF Security:
http://www.code-magazine.com/articleprint.aspx?quickid=0611051

<<Part One>>

Fundamentals of WCF Security (Part One)

<<Part Two>>

Fundamentals of WCF Security (Part One):

Building distributed applications has never been easy. As the applications that we write satisfy more complex business requirements, it’s traditionally meant that the distributed applications we build get more complex themselves. It was the below types of development challenges in building distributed applications that drove the design goals of the Windows Communication Foundation (WCF). For example:

• Standards-based interoperability needs to be taken into account for communication across heterogeneous systems.
• Different programming models like Web services, distributed objects, and message queuing with different capabilities that are focused on different application scenarios to address development needs and these are often contain functionality and features that don’t combine well with one another.
• Security is critical for applications, but often complicated to implement.

WCF addresses a range of challenges for communicating applications. Three things stand out, however, as the most important aspects of WCF:

• Unification of existing .NET Framework communication technologies.
• Support for cross-vendor interoperability, including reliability, security, and transactions.
• Explicit service orientation.

Windows Communication Foundation (WCF) is a runtime and a set of APIs for creating systems that send messages between services and clients. The same infrastructure and APIs are used to create applications that communicate with other applications on the same computer system or on a system that resides in another company and is accessed over the Internet. It is designed to offer a manageable approach to distributed computing, broad interoperability, and direct support for service orientation. It supports many styles of distributed application development by providing a layered architecture. It is a secure, reliable, and scalable messaging platform for the .NET Framework 3.0. With WCF, SOAP messages can be transmitted over a variety of supported protocols including IPC (named pipes), TCP, HTTP and MSMQ. Like any distributed messaging platform, you must establish security policies for protecting messages and for authenticating and authorizing calls.
In simple words, WCF is a new framework for building distributed applications that enables developers to build secure, reliable service-oriented applications that integrate across platforms and interoperate with existing investments. It reduces the coding and complexity of developing, deploying and managing distributed applications by combining and extending the capabilities of existing Microsoft distributed systems technologies like Enterprise Services, System.Messaging, Remoting, ASMX, and WSE. WCF solutions can run within the context of a single machine, over company intranets, or across the Internet using a variety of protocols, formats, and message exchange patterns.

WCF Architecture:

WCF high-level view architecture is a two layered architecture consisting of a messaging layer and the service model. The Messaging layer handles the low-level messaging of WCF services. It moves messages around on the wire and provides messaging features like transport extensibility, reliability, and transport security. The Service Model sits on top of the Messaging layer. It is the API for building WCF services and is the coupling between the messaging and the CLR. It is where transactions get set up, it controls instancing of objects, etc. All features in messaging layer are exposed through the service model.

How it works:

Fundamental Security Concepts:

A consistent set of fundamental security concepts apply in any distributed messaging system. Consider a message from sender (the calling application) to receiver (the target service receiving the message for processing).

Core Security Concepts:

• Authentication : Process of identifying the message sender.
  • Mutual Authentication –a means for sender and receiver to identity one another, to prevent possible man-in-the-middle attacks.
• Authorization: Determining the rights of the authenticated party like what system features and functionality an authenticated message senders are entitled to execute.
• Integrity: Messages should be digitally signed to ensure they have not been altered between sender and receiver.
• Confidentiality: Sensitive messages or specific message parts should be encrypted to ensure they cannot be openly viewed on the wire.
• Reliability: Preventing replay and Denial Of Service.

WCF provides a rich and configurable environment for creating security policies and setting runtime behaviors to control these security features.

• Authentication (variety of mutual authentication mechanisms are supported by using)
• Implies passing appropriate credentials to identify callers
• Windows Tokens
• Username and Password
• Certificates
• Issued Tokens (in a federated environment).
• Services must also be identified
  • Windows tokens
  • certificates
• Authorization:
  • Authorization against the appropriate credential store and based on:
    • Windows Roles
    • ASP.NET Roles
    • Custom Authorization
• Integrity and Confidentiality (based on)
  • Symmetric Session Keys
  • Asymmetric Keys for “Single-hop protection”

Scope of the WCF Security Component:

WCF security spans multiple components in the WCF architecture. The main goal of security in WCF is to provide integrity, confidentiality, authentication, authorization, and auditing for the applications that are built on top with the WCF framework. WCF architecture splits these functions into the following pieces:

• Transfer security - Responsible for providing message confidentiality, data integrity, and authentication of communicating parties.
  • Protecting messages while transferred from point to point
    • Across network nodes
    • Between applications
    • Across interoperable boundaries
  • Encryption and digital signatures facilitate
  • Transport security is on the wire
  • Message security can traverse network nodes

  Transport Level Security:
  

  • It can be provided by using any one of SSL, TLS, IPSec.
  • It is a Point-to-point.
  • Transport level security applies to entire message

  Message Level Security:
  

  • Web services security (WS*) - The WS-Security implementation in WCF handles the following:
    • Serialization of security tokens to and from SOAP messages.
    • Authentication of security tokens.
    • Application and verification of message signatures.
    • Encryption and decryption of SOAP messages.
  • Secure to ultimate message receiver (through intermediaries (XML firewalls, proxies, etc.))
  • Secure message parts.
• Authorization - Responsible for providing a framework for making authorization decisions.
• Auditing - Responsible for logging security-related events to the audit log.

Please refer to my other post "Fundamentals of WCF Security (Part Two)" for more information on security related settings available in WCF.

<<Part Two>>