- ~ Posted by Deepak Kamboj on September 21, 2009
Windows Communication Foundation (WCF) 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. This article will discuss how WCF accomplishes this.
The core of WCF security is to address four important features:
-
Confidentiality: Is the information confidential between the sender and the receiver? This feature will ensure that “unauthorized” parties do not get the opportunity to view the message. You usually achieve this by utilizing encryption algorithms.
-
Integrity: This feature ensures that the receiver of the message gets the same information that the sender sends without any data tampering. You usually sign messages using digital signatures to achieve integrity.
-
Authentication: This is to verify who the sender is and who the receiver is. Are they known to the system or the application? Authentication is the process of establishing a clear identity for an entity, for example, by providing evidence such as username and password. Although this is clearly important for a service to understand of its callers, it is equally important that callers have an assurance that the service being called is the expected service and not an impostor.
-
Authorization: At the authorization stage, you know who the sender or the receiver is. However, you also need to know whether they are authorized to perform the action they are requesting from the application. Authorization can be performed by custom code in the service, native or custom authorization providers, ASP.NET roles, Windows groups, Active Directory, Authorization Manager, and other mechanisms.
These are the key features the WCF security model attempts to address. You achieve the physical implementation of addressing these issues by configuring bindings in WCF. WCF offers a rich set of binding to address these security issues. You also have the flexibility of extending or creating custom bindings to address specific security needs if necessary.
There are two major classifications of security within WCF; both are related to the security of what is transferred between a service and caller (sometimes called transfer security). The first concept is of protecting data as it is sent across the network, or “on the wire.” This is known as transport security. The other classification is called message security and is concerned with the protection that each message provides for itself, regardless of the transportation mechanism used.
Default Security Settings
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>
Transport security provides protection for the data sent, without regard to the contents. A common approach for this is to use Secure Sockets Layer (SSL) for encrypting and signing the contents of the packets sent over HTTPS. There are other transport security options as well, and the choice of options will depend on the particular WCF binding used. In fact, you will see that many options in WCF are configured to be secure by default, such as with TCP.
One limitation of transport security is that it relies on every “step” and participant in the network path having consistently configured security.
Message security focuses on ensuring the integrity and privacy of individual messages, without regard for the network. Through mechanisms such as encryption and signing via public and private keys, the message will be protected even if sent over an unprotected transport (such as plain HTTP).
<bindings>
<basicHttpBinding>
<binding name="MyBinding">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
</binding>
</basicHttpBinding>
</bindings>
- Tags: wcf
- Categories: WCF | C#
- ~ Posted by Deepak Kamboj on September 8, 2009
In this post I will explain the Difference between ASP.NET web service and programming WCF services like ASP.NET web services. It also discusses how we use the both technologies for developing the web services.
The development of web service with ASP.NET relies on defining data and relies on the XmlSerializer to transform data to or from a service.
Key issues with XmlSerializer to serialize .NET types to XML
- Only Public fields or Properties of .NET types can be translated into XML.
- Only the classes which implement IEnumerable interface.
- Classes that implement the IDictionary interface, such as Hash table can not be serialized.
The WCF uses the DataContractAttribute and DataMemeberAttribute to translate .NET FW types in to XML.
[DataContract]
public class Item
{
[DataMember]
public string ItemID;
[DataMember]
public decimal ItemQuantity;
[DataMember]
public decimal ItemPrice;
}
The DataContractAttribute can be applied to the class or a strcture. DataMemberAttribute can be applied to field or a property and theses fields or properties can be either public or private.
Important difference between DataContractSerializer and XMLSerializer.
- A practical benefit of the design of the DataContractSerializer is better performance over XMLserialization.
- XMLSerialization does not indicate the which fields or properties of the type are serialized into XML where as DataCotratSerializer Explicitly shows the which fields or properties are serialized into XML.
- The DataContractSerializer can translate the HashTable into XML.
Developing Service
To develop a service using ASP.NET we must add the WebService attribute to the class and WebMethodAttribute to any of the class methods.
Example
[WebService]
public class Service : System.Web.Services.WebService
{
[WebMethod]
public string Test(string strMsg)
{
return strMsg;
}
}
To develop a service in WCF we will write the following code
[ServiceContract]
public interface ITest
{
[OperationContract]
string ShowMessage(string strMsg);
}
public class Service : ITest
{
public string ShowMessage(string strMsg)
{
return strMsg;
}
}
The ServiceContractAttribute specifies that a interface defines a WCF service contract, OperationContract Attribute indicates which of the methods of the interface defines the operations of the service contract.
A class that implements the service contract is referred to as a service type in WCF.
Hosting the Service
ASP.NET web services are compiled into a class library assembly and a service file with an extension .asmx will have the code for the service. The service file is copied into the root of the ASP.NET application and Assembly will be copied to the bin directory. The application is accessible using url of the service file.
WCF Service can be hosted within IIS or WindowsActivationService.
- Compile the service type into a class library
- Copy the service file with an extension .SVC into a virtual directory and assembly into bin sub directory of the virtual directory.
- Copy the web.config file into the virtual directory.
Client Development
Clients for the ASP.NET Web services are generated using the command-line tool WSDL.EXE.
WCF uses the ServiceMetadata tool(svcutil.exe) to generate the client for the service.
Message Representation
The Header of the SOAP Message can be customized in ASP.NET Web service.
WCF provides attributes MessageContractAttribute , MessageHeaderAttribute and MessageBodyMemberAttribute to describe the structure of the SOAP Message.
Service Description
Issuing a HTTP GET Request with query WSDL causes ASP.NET to generate WSDL to describe the service. It returns the WSDL as response to the request.
The generated WSDL can be customized by deriving the class of ServiceDescriptionFormatExtension.
Issuing a Request with the query WSDL for the .svc file generates the WSDL. The WSDL that generated by WCF can customized by using ServiceMetadataBehavior class.
Exception Handling
In ASP.NET Web services, Unhandled exceptions are returned to the client as SOAP faults.
In WCF Services, unhandled exceptions are not returned to clients as SOAP faults. A configuration setting is provided to have the unhandled exceptions returned to clients for the purpose of debugging.
Backtrack: http://www.techbubbles.com/wcf/wcf-vs-aspnet-web-services/