The document discusses security concepts in Windows Communication Foundation including authentication, authorization, message integrity, and confidentiality. It describes how WCF supports various security modes and mechanisms at the transport and message levels including common configurations for client credential types, algorithm suites, and impersonation. The key aspects of securing a WCF service are defining a security policy and configuring the appropriate bindings, behaviors, and protection levels.

1. www.orbitone.com
Raas van Gaverestraat 83
B-9000 GENT, Belgium
E-mail info@orbitone.com
Website www.orbitone.com
Tel. +32 9 265 74 20
Fax +32 9 265 74 10
VAT BE 456.457.353
Bank 442-7059001-50 (KBC)
22 May, 2009 Windows Communication Foundation
Security, by Tom Pester

2. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester2
 To understand WCF security we have to explore the basic set of security
principals for authentication, authorization, and message transfer
protection.

3. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester3
 Consider a message from sender to receiver
 Authentication.
We typically think about authentication as identifying the message sender.
Mutual authentication involves authenticating both the sender and the message receiver, to
prevent possible man-in-the-middle attacks.
 Authorization.
After authenticating the message sender, authorization determines what system features and
functionality they are entitled to execute.
 Integrity.
Messages should be digitally signed to ensure they have not been altered between sender and
receiver.
 Confidentiality.
Sensitive messages should be encrypted to ensure they cannot be openly viewed on the wire.

4. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester4
 A variety of mutual authentication mechanisms are supported using token formats such
as Windows tokens, username and password, certificates and issued tokens (in a
federated environment)
 Authorization can be based on Windows roles, ASP.NET roles or you can provide custom
authorization policies.

5. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester5
 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.

6. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester6
 Your binding selection will influence the available configuration options
 Beyond bindings, behaviors also provide information about client and service credentials,
and affect how authorization is handled.

7. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester7
 Each binding has a default set of security settings. 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>

8. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester8
 Lets look at the expanded binding configuration illustrating the default settings.
 <netTcpBinding>
<binding name="netTcp">
<security mode="Transport">
<transport clientCredentialType="Windows" />
</security>
</binding>
</netTcpBinding>
 NetTcpBinding is secure by default. Specifically, callers must provide Windows credentials
for authentication and all message packets are signed and encrypted over TCP protocol.
 In fact all standard bindings are secure by default except for Basic Http binding

9. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester9
Security Mode
 Across all service bindings there are five possible security modes:
 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.

10. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester10
 For example, this <wsHttpBinding> snippet illustrates how to require UserName
credentials be passed with the message.
 <wsHttpBinding>
<binding name="wsHttp">
<security mode="Message">
<message clientCredentialType="UserName" />
</security>
</binding>
</wsHttpBinding>

11. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester11
Transfer protection
 Transport vs. Message
 Transport protection is only good from point-to-point.
 Message protections is good end-to-end

12. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester12
 Messages are unencrypted over a channel stack that is unsecure

13. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester13
 Messages are encyrpted over a channel stack that is unsecure

14. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester14
 Messages are unencyrpted over a channel stack that is secure (If the channel were
unsecure, you could see the messages in clear text.)

15. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester15
 Messages are encyrpted over an unsecure channel between the client and the service
endpoint (1st hop). Notice the messages remain encrypted between the first service and
second service (2nd hop).

16. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester16
 Messages are unencyrpted over an secure channel between the client and the service
endpoint (1st hop). Notice the messages DO NOT remain encrypted between the first
service

17. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester17
 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.

18. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester18
 Transport security is point to point. Since the messages themselves are not encrypted,
once they go to another point, they can be potentially exposed to integrity/privacy attacks
as if they were unsecure.
 The big advantage of message security is that it provides end to end security. Messages
leaving intermediary services retain their security.

19. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester19
Client Credential Type
 The choice of client credential type depends on the security mode in place. Message
security supports any of the following settings for clientCredentialType:
 None
 Windows
 UserName
 Certificate
 IssuedToken

20. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester20
 <basicHttpBinding>
<binding name="basicHttp">
<security mode="TransportWithMessageCredential">
<message clientCredentialType="Certificate"/>
</security>
</binding>
</basicHttpBinding>

21. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester21
Protection Level
 By default, all secure WCF bindings will encrypt and sign messages. You cannot disable this
for transport security, however, for message security you may wish to disable this for
debugging purposes.
 Protection-level settings are controlled by the contract.

22. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester22
 [ServiceContract(Name="HelloIndigoContract",
Namespace=
"",
ProtectionLevel=ProtectionLevel.Sign)]
public interface IHelloIndigoService
{
string HelloIndigo(string inputString);
}

23. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester23
 For more granular control, you can also indicate message protection per operation using
the OperationContractAttribute.
 [ServiceContract(Name="HelloIndigoContract",
Namespace=]
public interface IHelloIndigoService
{
[OperationContract(ProtectionLevel=
ProtectionLevel.Sign)]
string HelloIndigo(string inputString);
}
 ProtectionLevel options are: None, Sign, and EncryptAndSign.

24. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester24
Algorithm Suite
 Choice of algorithm suite can be particularly important for interoperability.
 Each binding uses Basic256 as the default algorithm suite for message-level security
 <wsHttpBinding>
<binding name="wsHttp">
<security mode="Message">
<message clientCredentialType="UserName” algorithmSuite="TripleDes" />
</security>
</binding>
</wsHttpBinding>

25. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester25
Secure Session
 Another feature of message security is the ability to establish a secure session to reduce
the overhead of key exchange and validation.
 A token is generated through an initial exchange between caller and service. This token is
used to authorize and secure subsequent message exchanges.
 <wsHttpBinding>
<binding name="wsHttp">
<security mode="Message">
<message clientCredentialType="UserName"
establishSecurityContext="false" />
</security>
</binding>
</wsHttpBinding>

26. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester26
Authorisation
 <system.web> <membership defaultProvider="SqlProvider"
userIsOnlineTimeWindow="15"> <providers> <clear /> <add
name="SqlProvider" type="System.Web.Security.SqlMembershipProvider"
connectionStringName="SqlConn" applicationName="MembershipProvider"
enablePasswordRetrieval="false" enablePasswordReset="false"
requiresQuestionAndAnswer="false" requiresUniqueEmail="true"
passwordFormat="Hashed" /> </providers> </membership> <!-- Other configuration
code not shown.--></system.web>
 <behaviors>
 <behavior name="ServiceBehaviour">
 <serviceAuthorization principalPermissionMode ="UseAspNetRoles"
 roleProviderName ="SqlProvider" />
 </behavior>
 <!-- Other configuration code not shown. -->
 </behaviors>

27. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester27
 Imperatively
 public string AdminsOnly()
{
// unprotected code
PrincipalPermission p = new
PrincipalPermission(null, "Administrators");
p.Demand();
// protected code
}
 Or declaratively
 [PrincipalPermission(SecurityAction.Demand, Role =
"Administrators")]
public string AdminsOnly()
{
// protected code
}

28. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester28
Impersonation
 When Windows credentials are used, the service can be configured to impersonate callers
so that the request thread operates under the impersonated Windows token.
 This makes it possible for services to access protected Windows resources under the
identity of the caller, instead of the process identity of the service-for that request.
 This can be dangerous and I consider it bad practice.

29. 22 May, 2009
Windows Communication Foundation Security, by Tom Pester29
 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()
{
...
}

30. www.orbitone.com
30 Windows Communication Foundation Security, by Tom Pester
22 May, 2009