Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

.NET Web Services Security : Page 2

.NET has a lot to offer when it comes to both developing and consuming secure Web services. .NET allows developers to either rely on Windows-based authentication or develop custom authentication mechanisms. Each option has its own tradeoffs and implications on the programming models.


advertisement
Basic Windows Authentication
Basic authentication is an industry-standard authentication protocol (RFC 1945) that requires the caller to send credentials to the server. When you select the Basic authentication check box, IIS will deny access to incoming requests that do not include security credentials: domain, user name, and password. IIS will reply to requests lacking credentials with HTTP error 401. In the case of a Web page, using Basic authentication will cause the browser to display a dialog asking the user to enter network credentials. In the case of a Web service client, there is no browser, so it is up to the client to provide the credentials programmatically.

Consider, for example, the SecureCalculator Web service, defined as:

public class SecureCalculator { [WebMethod] public int Add(int num1,int num2) { return num1+num2; } }

If you configure this Web service to rely on Basic authentication, the client needs to provide the account credentials. The client may or may not be a Windows or .NET client. However, if the client is written in .NET, then it can use the built-in support that the client-side wrapper class has for passing network credentials (even when interacting with a non-Windows service that relies on Basic authentication). If you develop a client in .NET, when you add a Web reference to the SecureCalculator Web service, Visual Studio .NET generates a client-side SecureCalculator wrapper class that derives indirectly from WebClientProtocol. WebClientProtocol has a public property called Credentials, of type ICredentials. You'll find ICredentials in the System.Net namespace (see Listing 1 for the ICredentials definition). By default, the Credentials property is not initialized and is set to null. Before invoking a method on a Web service that uses Basic authentication, the client needs to initialize the Credentials property of the wrapper class with a NetworkCredentials object and then call the method:

using System.Net; SecureCalculator calc = new SecureCalculator(); ICredentials creds; creds = new NetworkCredential("UserName","Password","Domain"); calc.Credentials = creds; //Optional: calc.PreAuthenticate = true; calc.Add(2,3);

The client can also set the PreAuthenticate property of the wrapper class to true. This will cause the wrapper class to send credentials to the server, even when not challenged for them. This is an optimization option that can save the round trip after receiving a 401 error.

It is important to note that Basic authentication sends credentials in clear text, so you should use HTTPS or SSL, especially when using Basic authentication over the Internet. If the credentials are static, that is, they are not a run-time parameter the client retrieves somehow, then the client can encapsulate setting the credentials in the constructor of the wrapper class:


public class SecureCalculator : SoapHttpClientProtocol { public SecureCalculator () { ICredentials creds; creds = new NetworkCredential("UserName", "Password","Domain"); Credentials = creds; Url = "http://<...>/SecureCalculator.asmx"; } //Method wrappers... } SecureCalculator calc = new SecureCalculator(); Calc.Add(2,3);

Digest Windows Authentication
Digest authentication uses a special hashing algorithm (MD5) to avoid sending passwords in clear text over HTTP, and does not require HTTPS. Digest authentication is an industry standard (RFC 2617) supported natively by IIS. However, it does require using Active Directory to store the password. If you are not using Active Directory, the Digest authentication option will be disabled on the Authentication Methods dialog box in IIS (see Figure 1).

If you select to use Digest authentication, IIS will look in the request for the digest credentials and authenticate the user accordingly. There is nothing the Web service developer needs to do; it is up to the client to pass the digested credentials. If the client is a .NET client, it needs to initialize the Credentials property of the wrapper class with an object of type CredentialCache, as defined in Listing 2. CredentialCache is a collection of credentials that is polymorphic with ICredentials.

When using Windows security, there is nothing the Web service developer is required to do beyond configuring the Web service appropriately.
The client needs to construct individual credentials and add them to the cache, while specifying the type of the credentials using a non-type-safe string. Then, just as when using Basic authentication, the client needs to initialize the Credentials property of the wrapper class with the CredentialCache, optionally enable pre-authentication, and call the method:

SecureCalculator calc = new SecureCalculator(); ICredentials credsCache = new CredentialCache(); Uri uriPrefix = new Uri("<Service URL>"); ICredentials creds; creds = new NetworkCredential("UserName", "Password","Domain"); credsCache.Add(uriPrefix,"Digest",creds); calc.Credentials = credsCache; calc.PreAuthenticate = true;//Optional calc.Add(2,3);

With static credentials, the client can also encapsulate these settings in the wrapper class constructor.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date