How Wcf is more secure than Websevices?

Following security used in WCF

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.

For more Details:-
http://wcfsecurityguide.codeplex.com/wikipage?title=Ch%2004%20-%20WCF%20Security%20Fundamentals&referringTitle=Home


Security
WSE 3.0 Web services that are secured using a policy file

WCF services can use a configuration file to secure a service and that mechanism is similar to a WSE 3.0 policy file. In WSE 3.0 when securing a Web service using a policy file, you use either a turnkey security assertion or a custom policy assertion. The turnkey security assertions map closely to the authentication mode of a WCF security binding element. Not only are the WCF authentication modes and WSE 3.0 turnkey security assertions named the same or similarly, they secure the messages using the same credential types. For instance, the usernameForCertificate turnkey security assertion in WSE 3.0 maps to the UsernameForCertificate authentication mode in WCF. The following code examples demonstrate how a minimal policy that uses the usernameForCertificate turnkey security assertion in WSE 3.0 maps to a UsernameForCertificate authentication mode in WCF in a custom binding.

WSE 3.0
Copy

<policies>
<policy name="MyPolicy">
<usernameForCertificate messageProtectionOrder="SignBeforeEncrypt"
requireDeriveKeys="true"/>
</policy>
</policies>

WCF
Copy

<customBinding>
<binding name="MyBinding">
<security authenticationMode="UserNameForCertificate" 
messageProtectionOrder="SignBeforeEncrypt"
requireDerivedKeys="true"/>
</binding>
</customBinding>

To migrate the security settings of a WSE 3.0 Web service that are specified in a policy file to WCF, a custom binding must be created in a configuration file and the turnkey security assertion must be set to its equivalent authentication mode. Additionally, the custom binding must be configured to use the August 2004 WS-Addressing specification when WSE 3.0 clients communicate with the service. When the migrated WCF service does not require communication with WSE 3.0 clients and must only maintain security parity, consider using the WCF system-defined bindings with appropriate security settings instead of creating a custom binding.

The following table lists the mapping between a WSE 3.0 policy file and the equivalent custom binding in WCF.
WSE 3.0 Turnkey Security Assertion WCF custom binding configuration

<usernameOverTransportSecurity />

Copy

<customBinding>
<binding name="MyBinding">
<security authenticationMode="UserNameOverTransport" />
<textMessageEncoding messageVersion="Soap12WSAddressingAugust2004" />
</binding>
</customBinding>

<mutualCertificate10Security />

Copy

<customBinding>
<binding name="MyBinding">
<security messageSecurityVersion="WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10" authenticationMode="MutualCertificate" />
<textMessageEncoding messageVersion="Soap12WSAddressingAugust2004" />
</binding>
</customBinding>

<usernameForCertificateSecurity />

Copy

<customBinding>
<binding name="MyBinding">
<security authenticationMode="UsernameForCertificate"/>
<textMessageEncoding messageVersion="Soap12WSAddressingAugust2004" />
</binding>
</customBinding>

<anonymousForCertificateSecurity />

Copy

<customBinding>
<binding name="MyBinding">
<security authenticationMode="AnonymousForCertificate"/>
<textMessageEncoding messageVersion="Soap12WSAddressingAugust2004" />
</binding>
</customBinding>

<kerberosSecurity />

Copy

<customBinding>
<binding name="MyBinding">
<security authenticationMode="Kerberos"/>
<textMessageEncoding messageVersion="Soap12WSAddressingAugust2004" />
</binding>
</customBinding>

<mutualCertificate11Security />

Copy

<customBinding>
<binding name="MyBinding">
<security authenticationMode="MutualCertificate"/>
<textMessageEncoding messageVersion="Soap12WSAddressingAugust2004" />
</binding>
</customBinding>

For more information about creating custom bindings in WCF, see Custom Bindings.
WSE 3.0 Web services that are secured using application code

Whether WSE 3.0 or WCF is used, the security requirements can be specified in application code instead of in configuration. In WSE 3.0, this is accomplished by creating a class that derives from the Policy class and then by adding the requirements by calling the Add method. For more details about specifying the security requirements in code, see How to: Secure a Web Service Without Using a Policy File. In WCF, to specify security requirements in code, create an instance of the BindingElementCollection class and add an instance of a SecurityBindingElement to the BindingElementCollection. The security assertion requirements are set using the static authentication mode helper methods of the SecurityBindingElement class. For more details about specifying security requirements in code using WCF, see How to: Create a Custom Binding Using the SecurityBindingElement and How to: Create a SecurityBindingElement for a Specified Authentication Mode.
WSE 3.0 Custom Policy Assertion

In WSE 3.0 there are two types of custom policy assertions: those that secure a SOAP message and those that do not secure a SOAP message. Policy assertions that secure SOAP messages derive from WSE 3.0 SecurityPolicyAssertion class and the conceptual equivalent in WCF is the SecurityBindingElement class.

An important point to note is that the WSE 3.0 turnkey security assertions are a subset of the WCF authentication modes. If you have created a custom policy assertion in WSE 3.0, there may be an equivalent WCF authentication mode. For example, WSE 3.0 does not provide a CertificateOverTransport security assertion that is the equivalent to UsernameOverTransport turnkey security assertion, but uses an X.509 certificate for client authentication purposes. If you have defined your own custom policy assertion for this scenario, WCF makes the migration straightforward. WCF defines an authentication mode for this scenario, so you can take advantage of the static authentication mode helper methods to configure a WCF SecurityBindingElement.

When there is not a WCF authentication mode that is equivalent to a custom policy assertion that secures SOAP messages, derive a class from TransportSecurityBindingElement, SymmetricSecurityBindingElement or AsymmetricSecurityBindingElement WCF classes and specify the equivalent binding element. For more details, see How to: Create a Custom Binding Using the SecurityBindingElement.

To convert a custom policy assertion that does not secure a SOAP message, see Filtering and the sample Custom Message Interceptor.
WSE 3.0 Custom Security Token

The WCF programming model for creating a custom token is different than WSE 3.0. For details about creating a custom token in WSE, see Creating Custom Security Tokens. For details about creating a custom token in WCF, see How to: Create a Custom Token.


http://www.codeproject.com/KB/webservices/SOAPHeaderAuthentication.aspx