ASP.NET with Remoting Versus Web Services

for RuBoard

According to Encarta, the first definition of the word "remote" is as follows :

"re ·mote [ri mot ] adjective

1. far away: situated a long way away"

(Source: Encarta.com online dictionary)

The Case for Using ASP.NET with Remoting

First, let us look at remoting as a standalone item. Just the name sort of lends itself to being, well, alone. Why should we even consider remoting when DCOM has been faithfully there in Windows DNA for so long, especially considering that there is no built-in security in the TCPChannel class? DCOM has been a standard in Microsoft computing for years , yet with .NET, it has been dropped, completely ”or has it? The new kid on the block is called remoting. Remoting addresses some of the problems with DCOM while providing more of a "different" way of doing things instead of just a "new" way of doing things. Remoting provides communication between AppDomains and client/server components . DCOM introduced us to a way of invoking methods on other Windows machines that weren't necessarily part of the same Windows domain. Security was quite tight and difficult ”at least not easy ”to set up. There was also a performance question with DCOM in that, being based on COM, it had to use the counter callback reference to see if an instance existed. In DCOM, this was achieved by pinging the server by the client to see if the object was available. As of this writing, .NET remoting has come under some scrutiny by those who may not understand exactly what is available in .NET and start pouncing immediately on what they do not see. Remoting relies on an Application Domain as opposed to a Windows Domain. This level of granularity can actually be more secure because it gives you a higher level of control over specific assemblies. It is difficult to prepare an "apples-to-apples" comparison because they both approach the same problem from different angles. The improvements in .NET come from the acceptance of open specifications, such as SOAP. webMethods b2b Server and IBM server products have had this type of functionality for years in the Java Community. The basic premise stays the same, even though the names may have changed.

The concept of neither remoting, nor DCOM for that matter, strays too far from the basics of client/server programming. The main differences are that the client is not necessarily a client application such as a Web browser or custom fat-client form, and that by using .NET, you can actually "self-document" what it is that you are exposing ”not to mention the lack of "dll hell." When using remoting with ASP.NET, you are provided access to a way of blending the best of distributed computing with the presentation benefits of ASP.

Enough theory, let's look at the players in remoting. Because all of this starts with an Application Domain, we will look at the AppDomain class. Application Domain and AppDomain are synonymous. An AppDomain is a virtual, isolated (secure) environment established for the execution of a process. An AppDomain also has the ability to separate managed applications at runtime. AppDomain implements the IEvidenceFactory and MarshalByRefObject classes. The IEvidenceFactory gets an object Evidence . The Evidence class, an ICollection , contains information about an object. This information is related to what is relevant to an object, such as URI, code signing information, site name, and so on. The CLR will use this information to make decisions about security and permissions at runtime. Table 28.1 shows the default elements available to the Evidence class.

Table 28.1. Default Evidence Elements

Element	Description
Application Directory	The directory in which the application is installed
Hash	A cryptographic hash or key
Publisher	An Authenticode signature of the publisher of the code
Site	The site publishing the software, such as http://www.samspublishing.com
Strong name	A cryptographically generated strong name for the assembly
URL	The URL where the software can be located, such as http://www.samspublishing.com/ myservices .asmx
Zone	Relates the Security Zones available, such as Internet Zone, Intranet Zone, and so on

MarshalByRefObject is the base class that components running within an AppDomain , on different machines, communicate with by using application proxies. If more than one AppDomain exists on the same machine, they communicate directly with each other. The use of MarshalByRefObject over implicit marshalling by value ( MarshalByValObject ) is more efficient when using MarshalByRef . Only a proxy to the application is passed, whereas when using MarshalByVal , an entire copy of the application being called is passed to the client.

Listing 28.1 shows a simple implementation of the AppDomain class to set the current security policy on the application to that of the calling user . The first line of code shows the declaration of the class implementing MarshalByRefObject .

Listing 28.1 AppDomain Snippet

 public class SnippetClass : MarshalByRefObject     {         public void myFunction()         { AppDomain.CurrentDomain.SetPrincipalPolicy (PrincipalPolicy.WindowsPrincipal);         ... more code... 

What that one simple line of code does is to establish a context for everything that happens after it. Because this is an ASP.NET application, it's quite easy to catch the IIdentity implementation in the form of a WindowsIdentity class. Listing 28.2 shows the creation of this class.

Listing 28.2 Creation of the WindowsIdentity Class

 WindowsIdentity wi = (WindowsIdentity)this.User.Identity; 

From this point, one more line of code will get you the calling user's information in the form of a WindowsPermission class implementation. Listing 28.3 shows this.

Listing 28.3 WindowsPermission Creation

 WindowsPrincipal wp = new WindowsPrincipal(wi); 

NOTE

In Chapter 27, "Writing a Secure Web Site Using ASP.NET," Listing 27.5 contains a complete code sample showing the properties that can be retrieved using the WindowsIdentity class.

In closing arguments, remoting provides a secure, reliable means by which to allow code to execute behind the presentation layer that is provided for by ASP.NET. While ASP.NET can handle the execution, remoting within ASP.NET provides a more robust means of handling permissions and security for individual assemblies through containing them in the AppDomain . In addition, the authentication and authorization methods discussed in Chapter 14, "Authentication: Know Who Is Accessing Your Site," and Chapter 15, "Authorization: Control Who Is Accessing Your Site," apply to both ASP.NET using remoting and Web Services.

NOTE

In this context, the use of "presentation layer" refers to the common terminology for n- tier application architecture, where there is a defined presentation layer, business logic layer, and a data layer.

Now that we've looked at the highlights of remoting, what about Web Services? With what is available through remoting, why use Web Services? Here's why. Using ASP.NET with remoting to control who can execute code and what code can execute is an excellent use of managing the presentation layer of an application. Web Services come into play when there is an absence of or an unknown presentation layer.

The Case for Using Web Services

Web Services is being touted as one of the most exciting new features of .NET, and with good reason. Like remoting, when it comes to executing code, gathering data, or any other valid use for distributed computing, Web Services can be used to enhance an application by providing a secure means of execution. As an added bonus, Microsoft has made sure that Web Services have at least three means of exchanging information ”XML, SOAP, and binary. At the basic level, Web Services return data in an XML document format. As stated numerous times over the last several months, using XML allows data to be read into classes via parsing. This is a very generic, often scalable means of transferring data from different servers. This is because of the close relation between parsing an XML document and the use of a forward-only cursor in a database. At the next level, there is the HTTPChannel class, which allows secure communication, through SSL support, by exchanging SOAP messages with other servers. Finally, there is the TCPChannel class. This class allows for every exchange of information possible with the HTTPChannel and intense flexibility through the creation of custom serializers. More information on channels can be located in Chapter 16, "Data Transport Integrity: Keeping Data Uncorrupted." The code sample in Listing 28.4 illustrates using a Web Service to verify a hash value that has been passed. It also illustrates creating a method that is capable of creating hashes. In the real world, functionality like this could be used for custom authentication schemes, file decryption techniques, or for generating a value to be added to a SOAP header.

Listing 28.4 CryptText Web Service

 using System; using System.Collections; using System.ComponentModel; using System.Data; using System.Diagnostics; using System.Web; using System.Web.Services; using System.NET; using System.Security.Cryptography; ///This is here for the Unicode functionality using System.Text; namespace Chapter28 {  /// <summary>  /// Summary description for CryptText.  /// </summary>  public class CryptText : System.Web.Services.WebService  {   public CryptText()   {    //CODEGEN: This call is required by    // the ASP.NET Web Services Designer    InitializeComponent();   }   public static Byte[] ConvertStringToByteArray(String s)   {    ///<summary>    ///This function is quite important when working with    ///hashing routines.    ///</summary>    return (new UnicodeEncoding()).GetBytes(s);   }   public static string ConvertByteArrayToString(Byte[] b)   {    ///<summary>    ///This function is quite useful as well    ///when working with hashing routines.    ///</summary>    string s_tempStr = "";    s_tempStr = BitConverter.ToString(b);    s_tempStr = s_tempStr.Replace("-", "");    return(s_tempStr);   }   #region Component Designer generated code   //Required by the Web Services Designer   private IContainer components = null;   /// <summary>   /// Required method for Designer support - do not modify   /// the contents of this method with the code editor.   /// </summary>   private void InitializeComponent()   {   }   /// <summary>   /// Clean up any resources being used.   /// </summary>   protected override void Dispose( bool disposing )   {    if(disposing && components != null)    {     components.Dispose();    }    base.Dispose(disposing);   }   #endregion   [WebMethod]    ///<summary>    ///Create a large byte array to hold the string    ///coming in    ///</summary>   public String EncryptedString(String sToEncrypt)   {    //Create buffers for the byte arrays needed    //by the CSP    Byte[] bOfString = ConvertStringToByteArray(sToEncrypt);    byte[] results;    //Create an instance of the    //MD5 CSP    MD5CryptoServiceProvider md5 = new MD5CryptoServiceProvider();    //Generate the hash    results = md5.ComputeHash(bOfString);    //Return the string equivalent to    //the caller    return (ConvertByteArrayToString(results));   }   [WebMethod]   /// <summary>   /// Check hash will compare hash value sent   /// to an unhashed value. Note that as this is   /// a web service, everything must start out   /// as a string   /// </summary>   public String CheckHash(String sToHash, String sentHash)   {    //Same as above    Byte[] bOfHash = ConvertStringToByteArray(sToHash);    byte[] hashedValue = (new MD5CryptoServiceProvider()).ComputeHash(bOfHash);    //Instead of returning the string of a hash    //compare it    string sCheckHash = (ConvertByteArrayToString(hashedValue));    if(sentHash != sCheckHash)    {     return("The hashes did not match values sent were " + sCheckHash + " and " + sentHash  );    }    else    {     return("The hashes match");    }   }  } } 

When using the CryptText Web Service (refer to Listing 28.4), there are a few things to remember. The first is that it is based in XML, meaning that all data coming in is going to be a string, so functions must exist to handle this. The next thing is just how easy it is to implement the MD5CryptoServiceProvider . While this service contains very few lines of code, it performs a very valuable service, quite similar in theory to how digest authentication works. The last thing to take away from this sample is the use of Unicode to keep internationalization options open. This comes in to play frequently when creating true world-wide Web sites.

for RuBoard