XML Web Services are part of ASP.NET. As such they use the same security model that ASP.NET uses. This means you can pick from Windows basic authentication, Windows basic authentication with secure sockets, Windows digest, Windows client certificates, Forms, and custom security in SOAP headers.
By default the Web.config file is configured to run the Web Service using Windows basic authentication, which is suitable for intranet Web Services or Web Services such as you are likely to use for application integration within the same enterprise. The reason for this basic kind of default authentication is so that you don't have to struggle with security while you are learning Web Service basics. Now that you have the fundamentals out of the way, you need to know how to apply security to Web Services. In this section I will demonstrate basic Windows authentication. (Refer to Chapter 18 for more on general security.)
Exploring the Default Web.config File
The default Web.config file created with each Web Service is shown in Listing 13.6. The parts we are interested in vis- -vis security are highlighted in bold.
Listing 13.6 The Default Web.config File
Regarding security, the parts of the Web.config file we are concerned with are the authentication (lines 26 through 31) and authorization (lines 34 through 49) sections. If you examine the file, you can determine that the default authentication mode is Windows basic (line 31) and all users are allowed access (line 42). To change the security settings, we will have to change the Web.config file. Then clients will have to authenticate in coordination with the security model we select.
Using Windows Authentication at the File or Directory Level
You can use Windows authentication with Web Services. Windows authentication will work fine in all Windows intranet solutions. If a user attempts to run a Web Service and the current user name and password are not authorized, a Windows user name and password dialog (Figure 13.9) will be displayed, prompting the user for a new user name and password. If the user name and password entered cannot be authenticated, an Error 401 Not Authorized page will be displayed (Figure 13.10).
Figure 13.9. The Windows XP user name and password dialog displayed for Windows authentication.
Figure 13.10. The standard Error 401 page displayed, for example, when a user unsuccessfully attempts to authenticate.
To define allowed users you can create several user names and assign them to a common new role, or you can define individual allowed user names. The first step is to add the user names and roles to the Windows file system, giving either the individual users or the roles access to the deployed Web Services files. As the nameWindows authenticationsuggests, you are adding these users and roles to the access control list (ACL, pronounced ackle ). After the users are added to the ACL for the Web Services files, you need to modify the Web.config file, adding the allowed and denied users to the authentication portion of the file. I will break down each piece of the process in the subsections that follow.
Adding Users or Roles to the Access Control List
We will use a specific scenario for the Commissions Web Service. We want only users in the broker_dealer group to be able to access the Web Service, so we will create a broker_dealer group and add users to that group. Only users in this group will be authenticated. For our purposes we will assume that the Web Service is deployed in a folder named MyCommissions on the IIS server.
To prepare the deployed Web Service and configure users for Windows authentication, follow the numbered steps, using the figures as a pictorial guide.
After step 15 we are ready to modify the Web.config file. The Everyone account has access to the physical file folder. This allows us to modify the contents when we have physical access to the machine. For example, we'll need this access to modify the Web.config file. However, users browsing to our Web Service will be coming across an HTTP connection. They will be authorized based on the Windows users and groups and the settings in the Web.config file.
Modifying the Web.config File's Authorization Section
Windows authentication combines Windows security and ASP.NET security. It won't do any good to provide permission in a Web.config file if physical file access is blocked. By defining the broker_dealer group and adding users to that group (in Windows), we have sufficiently prepared the file system. Now we will modify the Web.config file.
Continuing our scenario, we want to allow only broker_dealer members to access the Commissions Web Service. By default the authentication mode is set to Windows. This is what we want. All we need to modify is the authorization section. Based on an excerpt from Listing 13.6 (without the comments), Listing 13.7 contains the authentication and authorization sections of the Web.config file, updated for MyCommissions.
Listing 13.7 The Updated Authentication and Authorization Sections
<authentication mode="Windows" /> <authorization> <allow roles="lap800\broker_dealer" /> <deny users="*" /> </authorization>
The Web.config file is read from top to bottom. The authorization section is read until an allow or deny section satisfies a request. Hence, if a user is authenticated and authorized by an allow section, no more processing occurs. The allow section in Listing 13.7 allows access by anyone in the broker_dealer group of lap800 (my laptop's name) and denies access by all other users.
You can verify your configuration by navigating to the Web Service using your browser. A user name and password dialog appears. If you enter one of the users defined as a member of the broker_dealer group and the password is correct, you should be able to browse to the Web Service page. (Remember to use the domain name. For example, lap800\AFonzarelli was one of the members I defined; this information would be entered as the user's name.) Unauthorized user names should be presented with the Error 401 Not Authorized page.