Understanding XML Web Services and Security

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

 1:  <?xml version="1.0" encoding="utf-8" ?> 2:  <configuration> 3: 4:    <system.web> 5: 6:      <!--  DYNAMIC DEBUG COMPILATION 7:        Set compilation debug="true" to insert 8:        debugging symbols (.pdb information) 9:        into the compiled page. Because this 10:       creates a larger file that executes 11:       more slowly, you should set this value to 12:       true only when debugging and to 13:       false at all other times. For more information, 14:       refer to the documentation about 15:       debugging ASP.NET files. 16:     --> 17:     <compilation defaultLanguage="vb" debug="true" /> 18: 19:     <!--  CUSTOM ERROR MESSAGES 20:       Set customErrors mode="On" or "RemoteOnly" 21:       to enable custom error messages, "Off" to disable. 22:       Add <error> tags for each of the errors you want to handle. 23:     --> 24:     <customErrors mode="RemoteOnly" /> 25:  26:     <!--  AUTHENTICATION   27:       This section sets the authentication policies of   28:       the application. Possible modes are "Windows",   29:       "Forms", "Passport", and "None"   30:     -->   31:     <authentication mode="Windows" />  32: 33:  34:     <!--  AUTHORIZATION   35:       This section sets the authorization policies of   36:       the application. You can allow or deny access   37:       to application resources by user or role. Wildcards:   38:       "*" means everyone, "?" means anonymous   39:       (unauthenticated) users.   40:     -->   41:     <authorization>   42:       <allow users="*" /> <!-- Allow all users -->   43:   44:       <!--  <allow users="[comma separated list of users]"   45:                    roles="[comma separated list of roles]"/>   46:             <deny users="[comma separated list of users]"   47:                    roles="[comma separated list of roles]"/>   48:       -->   49:     </authorization>  50: 51:     <!--  APPLICATION-LEVEL TRACE LOGGING 52:       Application-level tracing enables trace log output 53:       for every page within an application. 54:       Set trace enabled="true" to enable application trace 55:       logging.  If pageOutput="true", the 56:       trace information will be displayed at the bottom of 57:       each page.  Otherwise, you can view the 58:       application trace log by browsing the "trace.axd" 59:       page from your Web application 60:       root. 61:     --> 62:     <trace enabled="false" requestLimit="10" pageOutput="false" 63:     traceMode="SortByTime" localOnly="true" /> 64: 65: 66:     <!--  SESSION STATE SETTINGS 67:       By default ASP.NET uses cookies to identify which 68:       requests belong to a particular session. 69:       If cookies are not available, a session can be 70:       tracked by adding a session identifier to the URL. 71:       To disable cookies, set sessionState cookieless="true". 72:     --> 73:     <sessionState 74:       mode="InProc" 75:       stateConnectionString="tcpip=127.0.0.1:42424" 76:       sqlConnectionString= 77:       "data source=127.0.0.1;user id=sa;password=" 78:       cookieless="false" 79:       timeout="20" 80:     /> 81:     <!--  GLOBALIZATION 82:       This section sets the globalization settings of 83:       the application. --> 84:     <globalization requestEncoding="utf-8" responseEncoding="utf-8" /> 85: 86:   </system.web> 87: 88: </configuration> 

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.

NOTE

The description and figures in this subsection for deploying a Web Service and configuring the Web Service for Windows authentication are particular to Windows XP. The process for configuring Windows 2000 is very similar.

To prepare the deployed Web Service and configure users for Windows authentication, follow the numbered steps, using the figures as a pictorial guide.

1. Open the Computer Management console by selecting Manage from the right-click menu for MyComputer (on your desktop). Select the Local Users and Groups section (Figure 13.11).

   Figure 13.11. The Computer Management console is a central location for managing users, groups, services, and other facets of your system.

   

2. Select the Groups item and pick New Group from the context menu.

3. In the New Group dialog, enter the Group name broker_dealer and click Create (Figure 13.12). Close the New Group dialog.

   Figure 13.12. Define the broker_dealer group in the New Group dialog.

   

4. In the Computer Management dialog (Figure 13.11), Local Users and Groups, select the Users item and pick New User from the context menu (Figure 13.13).

   Figure 13.13. Create new users in the New User dialog.

   

5. Using Figure 13.13 as a guide, create a couple of users by entering a user name, a full name, and a password. Click the Create button when each user's information is ready.

6. After you have created the new users and closed the New User dialog, select the users in the Computer Management dialog. Double-click to the user properties (Figure 13.14), change to the Member Of tab, and make the users members of the broker_dealer group.

   Figure 13.14. Modify the Member Of list, making the users members of the broker_dealer group.

   

7. Deploy the Web Service by making a new folder. Copy the .asmx file and the project's Web.config file to the deployment folder. Add a bin directory and place Commissions.dll in the bin folder.

8. Return to the Computer Management console and select Services and Applications, Internet Information Services.

9. Click Default Web Site and select NewVirtual Directory from the context menu.

10. Using the Virtual Directory Creation Wizard, name the virtual directory MyCommissions and set the physical file path to the directory created in step 7. Use the defaults for everything else.

11. After you have deployed the Web Service and created the Web application directory, open Windows Explorer. (We need to set directory and file permissions.)

12. Navigate to the physical directory for MyCommissions, and select Properties from the context menu.

13. In the MyCommissions Properties dialog, select the Security tab.

14. Click Add and add the broker_dealer group to group or user names lists (Figure 13.15).

    Figure 13.15. Add the broker_dealer group to the list of authorized groups and users.

    

15. Add the Everyone user, too. Give the Everyone user Full Control and the broker_Dealer group Read and Execute permissions (Figure 13.16).

    Figure 13.16. We will need Read and Execute permissions to run the Web Service.

    

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.