Securing ASP.NET Web Services XML

In this section, we introduce you to securing ASP.NET Web services. You explore securing a Web service by using Windows authentication and by creating a custom security option.

Securing a Web Service by Using Windows Authentication

The process of securing a Web service involves authenticating a user and validating his authorization. In simple terms, the username and password of the user who tries to access the Web service are verified; if the username and password are valid, the user's rights are verified. If the user is authorized, he can access the Web service in two ways for an ASP.NET Web service, as discussed in the following list:

  • Using the authentication and authorization check facilities that Windows provides
  • Using a custom solution

Securing Web Services by Using Windows Authentication Methods

If you decide to use the first method of using the authentication and authorization check facilities, Windows provides you with several authentication methods, as detailed in the following list:

  • Basic. You can use this authentication method to identify users who log on. However, the Basic authentication method is not a very secure method because the username and password of the client are sent as base64-encoded strings in the text format, which can be easily decoded.
  • Basic with SSL. This authentication method is similar to the Basic authentication method, but it is more secure method because it uses SSL encryption to send the username and password. However, the security of this method is at the cost of the performance.
  • Digest. This authentication method encrypts the login data by hashing it and then transmits it. The digest authentication method is not supported by non-Windows platforms.
  • Integrated. This is the default Windows scheme that uses NTLM or Kerberos. It is an ideal authentication method for an intranet scenario, in which all users are working on the Windows platform and use Internet Explorer.
  • Client Certificates. You can obtain this authentication method from a CertificateAuthority (CA), such as VeriSign, and map it to user accounts. IIS uses the Client Certificates method to verify a user's access.

Note
For securing the Kshare Web service, you will use the Basic authentication method. However, if required, you can make the Web service more secure by using SSL.

To secure your Web service by configuring basic authentication, perform the following steps:

  1. Run Internet Services Manager from Administrative Tools, and expand the tree structure to view a list of all virtual directories in the default server.
  2. NoteYou will learn to create a virtual directory in the section "Deploying the
    Kshare Web Service."

  3. Right-click on the virtual directory for your Web service, and select the Properties option. The <virtual directory> Properties dialog box is displayed, as shown in Figure
  4. The <virtual directory> Properties Dialog Box.

    Securing ASP.NET Web Services

  5. Click on the Directory Security tab, as shown in Figure.
  6. The Directory Security Tab in the Properties Dialog Box.

    The Directory Security Tab in the Properties Dialog Box.

  7. In the Anonymous Access and Authentication Control section, click on the Edit button, which opens the Authentication Methods dialog box shown in Figure.
  8. The Authentication Methods Dialog Box.

    The Authentication Methods Dialog Box.

  9. If the Anonymous access check box is selected, deselect it. This deactivates anonymous access, which enables any user on the network to access the Web application.
  10. In the Authenticated Access section of the Authentication Methods dialog box, select the Basic Authentication (Password Is Sent in Clear Text) check box.
  11. Deselect the Integrated Windows Authentication check box, if it's selected. Windows displays a warning about the Basic authentication method being insecure. The warning is displayed in Figure.
  12. Warning Raised by Windows.

    Warning Raised by Windows.

  13. Click on the Yes button to close the warning.
  14. Click on the OK buttons to close all dialog boxes.

Modifying the Web.Config File

The next step in securing Web services is to modify the Web.Config file and set the mode attribute of the authentication element to Windows. The following code shows the Web.Config file and the changes made to the file:

Tip
Remember that you need to store the Web.Config file, which contains the authentication information, only in the root of the application or in the virtual directory. However, you cannot place this file in any of the subdirectories of the virtual directory.

You can use the Web.Config file to further set up the authorization levels for the application. We will not use authorization levels in this Web service. Using Web.Config for configuring authorization levels in a Web application is both simple and useful.

Consider a situation in which you want only authenticated users who belong to the category of group managers to be able to access a particular directory. In this case, you can use the configuration file, as shown in the following code:

As you can see, you can use two wild cards * and ? in the configuration file. * represents all users, whereas ? represents all unauthenticated users.

Now consider a situation in which you need to deny permission on a directory to all unauthenticated users. In this case, you use the following configuration file:

Passing Logon Credentials of the Clients

The next step in configuring the basic authentication method is to pass the logon credentials of the clients who access a Web service. To connect to the Web service, perform the following steps:

  1. Create an instance of the Web service proxy class.
  2. Create an instance of the NetworkCredential class and set its Username, Password, and Domain properties.
  3. Create an instance of the CredentialCache class and add the NetworkCredential class object to the CredentialCache class by using its Add() method.

The CredentialCache class stores authentication credentials for multiple Internet resources. Applications that need to access multiple resources can store the credentials for those resources in an object of this class and then provide the credentials when the Internet resource requests them. To do this, the CredentialCache class contains the following methods:

  • Add() method. This method adds an object of the type NeworkCredential class to the CredentialCache class. The syntax of the Add() method is as shown:
  • public void Add(Uri uriPrefix,string authType,NetworkCredential credo);

The following code shows an example of the Add() method:

  • GetCredential() method. This method returns the first matching credential. The syntax of the GetCredential() method is as shown:
  • Remove() method. This method deletes a credential from the cache. The syntax of the Remove() method is as shown:
  • public void Remove(Uri uriPrefix, string authType);

In the preceding discussion, the credential of the client is stored in an object of the NetworkCredential class. This class stores authentication credentials for Windows authentication schemes, such as Basic, Digest, and NTLM. The following code shows an example of the NetworkCredential class:

Next, you need to assign the instance of the CredentialCache class to the Credentials property of the proxy class, as shown in the following code sample:

After you perform these steps, your Web service is secured. A user can now call any of the Web methods that the Web service exposes.

Securing Web Services by Using a Custom Solution

As discussed, you can create a custom solution to secure a Web service. In this section, we will discuss a simple way to implement a custom authentication solution for a Web service.

In this method of authentication, you will create a Login Web service. This Web service is different from the Kshare Web service. The methods of this Web service can authenticate a client. To do this, the Web service contains a method LoginCheck() that accepts a username and password to authenticate a client. Then the method is added to a new Web service and isolated from the rest of the Web services; this enables a user to connect to this Web service through SSL.

As you know, SSL provides encryption and security, but it has performance problems. In a Web service, security is the main issue. Therefore, you will create a separate Web service to which a user can connect through SSL. The other Web services in the application will simply connect through HTTP.

For the Login Web service, you need a Users table and a Sessions table. The Users table contains a user's username and password. Whenever a user calls the LoginCheck() method, his username and password are validated. If the user's credentials are found to be valid, the LoginCheck() method generates a session ID for the user and returns it. Each 271 session ID that is created is valid for an hour and stored in the Sessions table. In addition, the Sessions table states the date and time when the corresponding session was created.

Now when a Web method is called, the Session ID is passed as part of the SOAP header message, and a check is made to see if the particular session ID exists in the Sessions table. In addition, it is confirmed that the session is not more than an hour old and is valid. The structures of the Users and Sessions table are shown in Figures:

The Users Table.

The Users Table.

The Sessions Table.

The Sessions Table.

Similar to the Kshare Web service, you will use stored procedures to access data from the database for the Login Web service. To validate the user's credential, create a stored procedure called Login. If the user credentials are validated, the stored procedure creates a new session ID by using the NewID() function, which is contained within the stored procedure. Then a new record for the session ID is added to the Sessions table. This record stores information such as the session ID and the user ID. In addition, when the record is added to the Sessions table, the last field in the table is updated with the current date and time. The code for the Login stored procedure is shown in the following code:

After you create the stored procedure, you need to implement the Login Web service. To do this, perform the following steps:

  1. Add a new Web service, Login, to your Web service project. This adds a Web service to the Kshare project and includes the standard Web service files to the project.
  2. Open the file Login.asmx.vb. This file provides functionality to the Web service. Add a new Web method called LoginCheck() to the Web service, as shown in the following code:

Note
Because the preceding code uses ADO.NET, you need to add the following statement along with the rest of the using statements: using System.Data.SqlClient

As you see, the LoginCheck() method accepts a user's login name and password and calls the Login stored procedure. Then the method retrieves the session ID from the parameter's collection and returns the session ID.

SOAP Headers

SOAP headers are a useful place to store data that is related to the SOAP message. The message is contained in the Body element of the SOAP message. For the Login Web service, you will create a SOAP header that is used to send the session ID created by the LoginCheck() method.

Sending session IDs in a SOAP message is preferred over sending usernames and passwords. The advantages to using session IDs are discussed in the following list:

  • The usernames and passwords are sent over the wire by using a Web service that is accessible through SSL, and is, therefore, secure. You learned about the advantages of SSL in "Creating a Web Service Using the Microsoft SOAP Toolkit."
  • Because only the Login Web service is on SSL, the performance of the Kshare Web service is not affected. To access other methods of the Kshare Web service, you can use the session ID that the LoginCheck() method returns. Because these methods do not use SSL, performance is not affected.
  • Even if a user gains access to the session ID, it will not be of much use because the session ID expires in an hour.

As you saw in "Introduction to SOAP," a SOAP message contains a Body element and an optional Header element within an Envelope. You can use the Header element to send and receive data that is not related to the message contained within the body of the message.

To create a SOAP header, you need to declare a class that derives from the SoapHeader class, as shown in the following code:

We will now discuss the SoapHeader class in detail. The SoapHeader class has the following properties:

  • Actor. This property specifies the recipient of the header.
  • DidUnderstand. This property specifies whether the recipient received and understood the header, if the MustUnderstand property is set to True.
  • EncodedMustUnderstand. This property specifies whether the recipient must understand and process a header, whose MustUnderstand property is true and whose value is encoded.
  • MustUnderstand. This property specifies whether the recipient must understand and process the header.

To send data in a SOAP header, you need to add a public variable to the class. The following code shows how to add a public string type variable to store the session ID:

After you declare the class, you need to add an instance of it to the Web service class, as shown in the following code:

Next, you need to add the SoapHeader attribute to all methods of the Web service that need to access these SOAP headers. For example, to ensure that the GetAllQueries() Web method has access to the session ID of th user, add the following code:

The preceding method retrieves the session ID from the SOAP header object, Service1Header, and passes it to the validateSession() method. The code for the validateSession() method is as shown:

Following are the properties of the SoapHeader attribute:

  • Direction property. This property specifies whether the header is received from the client, sent to the client, or both. When the Web service receives the SOAP message, the Web service sends a Receipt header to the client application, which, in turn, sends a Payment header to the Web service. To do this, you need to set the Direction property to SoapHeaderDirection.In and SoapHeaderDirection.Out, respectively. However, in cases in which the SOAP header is received from the client and returned to the client, the value of the Direction property is set to SoapHeaderDirection.InOut.
  • Required property. This property specifies whether you must include the Header element within the SOAP message so that the Web service considers the SOAP message valid. The Required property takes a Boolean value, either true or false. The true value, which is the default value of the Required property, indicates that it is essential to include the SOAP header. If the Required property is set to true and the required headers are not included in the SOAP message, a SoapException is thrown. If the Required property is set to false, ASP.NET cannot support the HTTP GET/POST bindings.
  • MustUnderstand property. This property specifies whether the Web service must understand and process the Header element of the SOAP message. Therefore, as you can see, to declare and access a SOAP header in a Web service, you need to perform the following steps:
  1. Declare a class that derives from the SoapHeader class.
  2. Create an instance of the SoapHeader class in your Web service class.
  3. Add the SoapHeader attribute to the methods of the Web service that need to access the SOAP header.

Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

XML Topics