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:
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:
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:
NoteYou will learn to create a virtual directory in the section "Deploying the
Kshare Web Service."
The <virtual directory> Properties Dialog Box.
The Directory Security Tab in the Properties Dialog Box.
The Authentication Methods Dialog Box.
Warning Raised by Windows.
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:
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:
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:
The following code shows an example of the Add() method:
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 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:
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 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:
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:
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:
XML Related Interview Questions
|Soap Tool Interview Questions||HTML Interview Questions|
|PHP Interview Questions||ASP.NET Interview Questions|
|PHP5 Interview Questions||Java Interview Questions|
|CSS Interview Questions||XSLT Interview Questions|
|Java XML Interview Questions||XMLHttpRequest (XHR) Interview Questions|
|ebXML Interview Questions||XML DOM Interview Questions|
|XML-RPC Interview Questions||XSD Interview Questions|
|Soap Web Services Interview Questions||XSL Interview Questions|
|Xml Publisher Interview Questions|
Basics Of Xml
Basics Of Web Services
Introduction To Soap
Introduction To Uddi
Introduction To Wsdl
Creating A Web Service Using The Microsoft Soap Toolkit
Building Web Applications On The .net Platform
Creating An Asp.net Web Service
Creating A Web Service From An Interface
Introduction To The Atl Server
Creating A Web Service Using The Atl Server Library
Design And Creation Of The Knowledge Share Web Service
Introduction To Java Xml Technologies
Developing Java Web Services
Design And Creation Of A Web Service Using The Ibm Toolkit
Introduction To Mobile Applications
Creating A Mobile Application That Consumes A Web Service
Web Services Development With Jdeveloper
Creating Web Services Using Perl
Integration Of Xml Web Services With The Office Xp And Sql
Server 2000 Toolkits
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.