Security over the Internet

I l @ ve RuBoard

Security in distributed applications is always an issue, and even more so with applications that use the Internet. We'll cover two important aspects of security in this section. The first aspect concerns restricting access to resources and applications running on the Web server to certain applications and individuals. You need a way to identify the source of any requests (authentication) and check that the source is allowed to perform any requested action (authorization) ”you don't want any old hacker to upload files onto your Web server or download sensitive data.

The second aspect concerns securing the data as it flows over the Internet. You never know who is listening and monitoring the packets flowing over the network. So another requirement is that sensitive data should not make sense if intercepted by an unauthorized third party. This means encrypting data.

Authentication and Authorization

The HTTP protocol defines a challenge/response mechanism for handling security. A client application attempting to access a resource will be challenged by the Web server hosting that resource to prove its identity. The client must reply with a token of some sort that identifies it and one that the Web server can verify. Once the client has been identified, the server can grant or deny access to resources on that server. The .NET Framework Class Library supports a variety of Internet authentication mechanisms ”Basic, Digest, Negotiate, NTLM, and Kerberos.

Tip

If you're accessing an ASP.NET resource running under IIS, the ASP.NET application should be configured to run using the Windows ASP.NET authentication provider. Configuration of IIS and ASP.NET applications is covered in more detail in Chapter 16.

In this model, when a WebRequest is issued to a Web server, the server will require the client to verify its identity. The common language runtime uses the System.Net.AuthenticationManager class to do this, and the Web client might not be aware of what is happening behind the scenes. This class delegates much of its work to authentication modules , which are classes that implement the System.Net.IAuthenticationModule interface and perform the actual authentication of requests.

.NET is preconfigured with modules that handle Basic, Digest, Negotiate, NTLM, and Kerberos authentication. Authentication modules must be registered with the authentication manager. When a client request requires authentication, the common language runtime invokes the authentication manager, which in turn calls the Authenticate method of each registered authentication module in turn until one of the modules returns a positive response (request allowed) or the list of modules is exhausted (request denied ).

Some authentication modules permit preauthentication. Preauthentication allows an authentication module to preemptively authenticate a Web client in the expectation that the server will require this to happen anyway ”this can save time when the client contacts the Web server and can also conserve bandwidth by not sending a request to the server in the first place if the authentication fails. Authentication modules are registered with the authentication manager using the static AuthenticationManager.Register method or in the <authenticationModules> section of the application configuration file:

 <configuration> <system.net> <authenticationModules> <addtype= "System.Net.DigestClient" /> <addtype= "System.Net.NegotiateClient" /> <addtype= "System.Net.KerberosClient" /> <addtype= "System.Net.NtlmClient" /> <addtype= "System.Net.BasicClient" /> </authenticationModules> <webRequestModules> </webRequestModules> </system.net> 

The Authenticate method parameters include the WebRequest object submitted by the client, which identifies the URI being accessed, and an ICredentials object that contains the credentials that help identify the client. A client request must therefore provide a set of credentials for the authentication system to validate. How these credentials are gathered depends on the authentication method the server expects when the client accesses a given resource. For example, if the URI demands Basic authentication, the client request must supply a username and password and store this information in the Credentials property of the WebRequest before submitting it. This can be achieved using a System.Net.NetworkCredential object:

 HttpWebRequestrequest= (HttpWebRequest)WebRequest.Create("http://www..."); NetworkCredentialcredentials= newNetworkCredential("username", "password"); request.set_Credentials(credentials); WebResponseresponse=request.GetResponse(); 

Note that if the requested URI does not authenticate users, any credential information supplied by the client will be ignored. Also, some authentication mechanisms (Digest, for example) expect a domain as well as a username and a password. The NetworkCredential constructor is overloaded, and one implementation takes an additional domain parameter.

You can also create a credential cache using the CredentialCache class, associating credentials with one or more URIs and authentication schemes (Basic, Digest, Kerberos, and so on). You can then attach this cache to WebRequest objects ”the same cache can be associated with multiple requests. The authentication module on the server can obtain the credentials associated with a particular URI and authentication scheme by calling the GetCredentials method of the cache dispatched with the request and validate them. Using a credential cache is useful for applications that need to access multiple Internet resources.

 //Createacredentialcache CredentialCachecache=newCredentialCache(); //Addcredentialstothecache cache.Add(newUri("http://www..."),"Basic", newNetworkCredential("username", "password")); cache.Add(newUri("http://www.../"),"Digest", newNetworkCredential("username", "password", "digestdomain")); HttpWebRequestrequest= (HttpWebRequest)WebRequest.Create("http://www.microsoft.com/ms.htm"); //AttachthecachetotheWebRequest request.set_Credentials(cache); //Submittherequest,withcredentialcache WebResponseresponse=request.GetResponse(); 

Kerberos and NTLM authentication can also specify user details, but a default set of credentials based on the Windows identity of the process running the application will also be generated. This information is accessible through the DefaultCredentials property of the CredentialCache object.

When authentication has completed, the Authenticate method returns a System.Net.Authorization object. The authorization object contains an authorization token in its Message property. The Web server examines this token when granting or denying access to protected resources. The contents of the Message property depend on the type of authentication performed ”different schemes generate different format messages. Authorization is essentially a task performed by the Web server once a client has been authenticated. (Authorization in ASP.NET applications will be covered in Chapter 16.)

Encryption

For data to be transmitted securely, it must be encrypted. One of the simplest ways to do this is to use SSL or Transport Layer Security (TLS). TLS/SSL uses public key encryption to secure the exchanges between the client and the Web server. If a Web server supports SSL, you can simply issue URIs of the form https ://www . The WebRequest class will automatically manufacture an appropriate object that you can use to communicate over SSL. SSL comes at a cost, though; performance tends to be slower due to the amount of encryption/decryption required. You might not notice this on a Web client (the Internet is almost always slow!), but you might find that the Web server requires additional processing power and memory to maintain speed. If you're using IIS, you must obtain and install a server certificate if you want to support SSL.

An alternative to using SSL to encrypt the channel communicating between the client and the server is to simply encrypt the payload of each message. The .NET Framework supports private-key encryption using encryption service providers in the System.Security.Cryptography namespace. Providers are available for a number of algorithms, including DES, Triple DES, RC2, and Rijndael. Public-key encryption is also available using providers for the RSA and DSA algorithms. The public-key algorithms can also be used to generate digital signatures, guaranteeing the identity of the sender of a message and its contents.

Hashing is another mechanism used to form digital signatures, and a variety of common hashing algorithms are supported, including MD5, SHA1, SHA256, SHA384, and SHA512, depending on the length of the hash key you require. The longer the hash, the more secure it will be, but the longer it will take to generate and decode. For more information on using the cryptographic services in .NET, see the .NET Framework SDK documentation.

I l @ ve RuBoard