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>>