This post presents a barebones yet complete demonstration of security policies suitable for the Intranet scenario.
Other posts in this series:
WCF Security Scenarios – Barebones (Overview)
WCF Security Scenarios – Barebones Part 2 (Anonymous)
WCF Security Scenarios – Barebones Part 3 (Business-to-Business)
WCF Security Scenarios – Barebones Part 4 (Internet)
Source code for all scenarios can be downloaded here.
Scenario: Intranet
They key characteristics of this scenario are:
- Interoperability: Not needed, client and server run Windows and WCF.
- Firewall: There is no need to cross a firewall.
- Point-to-Point: In an intranet the client and server communicate directly, there is no intermediary.
- Client Identity: The client has a Windows Identity which can be used for authentication and authorization.
Security Policy
- We can use the net tcp binding for efficient communication between WCF parties that does not cross a firewall.
- The security mode should be Transport as oppose to Message.
Message protection requires more processing and is not needed when there is no intermediary which might forward the message to its final destination over an insecure channel. - Windows identities will be used for mutual authentication (and authorization – though this is not demonstrated).
Service Configuration File
Here is the App.config:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<services>
<service name="CalculatorService.Calculator"
behaviorConfiguration="IntranetServiceBehavior">
<endpoint address="Calculator"
binding="netTcpBinding"
bindingConfiguration="IntranetBindingConfiguration"
contract="CalculatorService.ICalculator" />
<endpoint address="mex"
binding="mexTcpBinding"
contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="net.tcp://localhost/Services" />
</baseAddresses>
</host>
</service>
</services>
<bindings>
<netTcpBinding>
<binding name="IntranetBindingConfiguration">
<security mode="Transport">
<transport
clientCredentialType="Windows"
protectionLevel="EncryptAndSign"/>
</security>
</binding>
</netTcpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="IntranetServiceBehavior">
<serviceMetadata/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
Reading from the top:
This application hosts a service called Calculator.Service at an end point whose address is net.tcp://localhost/Services/Calculator, uses the netTcpBinding and exposes the CalculatorService.ICalculator contract.
The application also provides metadata on a mex endpoint (configured as an endpoint, and a serviceMetadata entry in the IntranetServiceBehavior at the bottom of the file).
The configuration for the netTcpBinding, called IntranetBindingConfiguration (are you following?) will be implementing Transport security to encrypt and sign all data that crosses the channel. Client credentials are derived from the client’s Windows identity.
Client Configuration File
Here is the App.config:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<client>
<endpoint address="net.tcp://localhost/Services/Calculator"
binding="netTcpBinding"
bindingConfiguration="IntranetBindingConfiguration"
contract="ServiceReferences.ICalculator">
</endpoint>
</client>
<bindings>
<netTcpBinding>
<binding name="IntranetBindingConfiguration">
<security mode="Transport">
<transport clientCredentialType="Windows"
protectionLevel="EncryptAndSign"/>
</security>
</binding>
</netTcpBinding>
</bindings>
</system.serviceModel>
</configuration>
Reading again from the top.
This application will instantiate proxies for the calculator service that will communicate across the endpoint whose address is net.tcp://localhost/Services/Calculator, that uses the netTcpBinding and exposes the CalculatorService.ICalculator contract.
The configuration for the netTcpBinding, called IntranetBindingConfiguration will be implementing Transport security to encrypt and sign all data that crosses the channel. Client credentials are derived from the client’s Windows identity.
That was fairly straightforward ...
Next is the Anonymous scenario which requires some certificate handling. Do I hear you groaning?
I promise to keep it simple . . .