Securing Web Services


The principles of securing Web services are exactly the same as securing Web sites, with the exception that Web services do not provide a user interface. Instead of returning HTML to the client, they return XML. Exactly what security features you need to implement depends on the nature of your Web service. Is it a public Web service returning public data to anonymous users? Is it a private Web service returning information only to subscribers? Here are some common design considerations for securing Web services:

  • Access Is your Web service available to an intranet, extranet, or the Internet? Do you need to restrict who can access the Web service based on where they are located? You can restrict what computers or domains can access your Web service by using the IP Address and Domain Name Restrictions settings in the Internet Information Services configuration utility.

  • Cross-Platform Is your Web service going to be used only by Microsoft Windows clients, or will it be a cross-platform service? As discussed in the next item, if the Web service is to be used only by Windows clients, Windows authentication can be used.

  • Authentication Does your Web service need to know who is calling it? Does the caller need to be identified and authenticated? Can the Web service be used in an anonymous mode, where the client requires no authentication? If your Web service is available only to subscribers, authentication will be important. Because Web services do not show a user interface, forms-based authentication cannot be used. Passport authentication is also difficult to implement. The three best options available are Windows authentication (if the clients are Windows machines); passing the username and password as part of the request; and using the functionality of the Web Services Enhancements download, available from http://msdn.microsoft.com/library /default.asp?url=/downloads/list/websrv.asp (although this requires that both the client and server install the download).

  • Authorization Assuming the user is authenticated, should the Web service restrict some actions or information to particular groups or individuals? For example, a Web service that returns stock market quotes might return real-time quotes to paid subscribers and delayed quotes to public users. You can use the role-based security techniques introduced in Chapter 2 to control who can do what with your Web service.

  • Transport-level security Does the information sent to and from the Web service need to be encrypted so that it’s protected from packet-sniffing software? An easy way to determine this is to ask yourself, “How would I feel if the information was printed on the front page of the newspaper?” If this concerns you, you should implement transport-level security with SSL as described earlier in this chapter.

  • Message security After a message has been securely transported from the client to the server or vice versa, should the message content also be protected from being tampered with on the client or the server? Does it matter if any program on the client calls the Web service, or should access be restricted to a particular program, or a program that has been previously authenticated? You should design your application to expect that even authenticated users might use rogue programs to send inappropriate requests.

  • Test mode Does your Web service need a test mode? If your Web service simply returns information, it probably doesn’t need a test mode. However, if your Web service performs some action such as debiting an account, running a process, or placing an order, you should create a non-live mode for the Web service so that other developers can make sure the Windows or Web applications they create work with your Web service without performing any action on the live data. The best way to implement a test mode is to set up a test Web server with the non-live service. The clients can switch between test and live modes simply by changing URLs.

start sidebar
Global XML Architecture

At the time of writing, Microsoft, IBM, and VeriSign are defining open standards and protocols that extend Web services to tackle real-world problems such as digitally signing, encrypting, adding credentials to assist with routing, attachments, and transaction support. These standards are known as GXA (Global XML Architecture), and are sometimes introduced with the WS- prefix, for example WS-Security. For an introduction to GXA, see the article “Understanding GXA” at this location:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dngxa/html/understandgxa.asp.

As mentioned earlier, you can download the Web Services Enhancements 1.0 for Microsoft .NET, which already contains many security features, from this location: http://msdn.microsoft.com/library/default.asp?url=/downloads/list/websrv.asp.

The standard is still evolving and will eventually provide simplified support for security across all platforms.

end sidebar

Secure a Web service

In this exercise, you will create a Web service that uses WMI (Windows Management Instrumentation) to report the free memory on the Web server and the status of the server. This Web service will use Windows authentication to obtain the name of the current user, and it will return the free memory and server status only if the user is a member of the Administrators group on the server. Finally, you will encrypt the information by using SSL security. This results in a simple example of a Web service for server administration.

  1. In Visual Basic .NET, create a new Web service named ServerStatus. When the Web service is created, the file Service1.asmx.vb is opened in the designer.

  2. In the References folder, add a reference to the .NET assembly System.Management. This assembly contains the WMI types.

  3. Double-click the background of the designer to open the code module for Service1.asmx.vb. Add the following lines of code to the Imports section at the top of the file:

     Imports System.Management
    Imports System.Security.Principal

  4. Add the following function to the file:

     <WebMethod()> Public Function _
    GetServerStatus() As String()
    Dim strReturn() As String
    Dim idy As WindowsIdentity
    Dim ppl As WindowsPrincipal
    ppl = CType(System.Threading.Thread.CurrentPrincipal, _
    WindowsPrincipal)
    idy = CType(ppl.Identity, WindowsIdentity)
    ’Check the user is an administrator
    If ppl.IsInRole(WindowsBuiltInRole.Administrator) Then
    Dim sch As New ManagementObjectSearcher( _
    "SELECT * FROM Win32_OperatingSystem")
    Dim res As ManagementObject
    ReDim strReturn(3)
    ’Get the available resources
    For Each res In sch.Get
    strReturn(1) = "Free physical memory = " & _
    res("FreePhysicalMemory").ToString
    strReturn(2) = "Free virtual memory = " & _
    res("FreeVirtualMemory").ToString
    strReturn(3) = "Server status = " & _
    res("Status").ToString
    Next res
    res.Dispose()
    sch.Dispose()
    Else
    ReDim strReturn(1)
    strReturn(1) = _ "You are not authorized to use this web service"
    End If
    strReturn(0) = "Current User = " & idy.Name
    Return strReturn
    End Function

  5. Open the Web.Config file, and add the following element just below the <authentication mode="Windows” /> element:

     <identity impersonate = "true"/>
  6. Also in the Web.Config file, change the <authorization> element to:

     <authorization>
    <deny users="?" />
    </authorization>
  7. Press F5 to run the Web service. If you are an administrator on the Web server, then after clicking the GetServerStatus link and then clicking the Invoke button, the Web service will return XML similar to what is shown here:

    click to expand

  8. To secure the Web service with SSL, start Internet Information Services Manager, open the Local Computer\Web Sites\Default Web site node, right-click the ServerStatus node, and click properties to open the ServerStatus properties dialog box.

  9. In the ServerStatus dialog box, select the Directory Security tab. Click the Edit button in the Secure Communications section to open the Secure Communications dialog box.

  10. Check the Require Secure Communications check box, and click OK to save these changes. Users will be able to access the Web service only by using https protocol.

  11. Finally, you have to configure Visual Studio .NET to use https when debugging the Web service. To do this, open the project properties pages, select Configuration Properties|Debugging, and change the start action from Start Project to Start URL, using the absolute URL to your Web service as shown in the illustration on the following page.

    click to expand

    In this example, the author’s machine name PUKEKO is shown. In your own application, you should use the name of your own machine. If you’re tempted to use LocalHost, don’t—SSL checks that the machine name in the URL matches the machine name in the certificate and will report an invalid certificate if the two names don’t match.

  12. Press F5 to run your Web service. The data will now be encrypted automatically using SSL. If the server is under load, you might notice a slight degradation in performance, since the computer has to do extra work encrypting and decrypting.

start sidebar
Windows Management Instrumentation

The previous exercise uses WMI (Windows Management Instrumentation) to retrieve the server’s free memory and overall status. The WMI classes enable you to automate, administer, and retrieve almost any information about the local machine or any remote machine you are authorized to administer. These classes are very powerful, but do take some time to master. Here is some more information to help you start using WML. The previous exercise retrieved information from the Win32_OperatingSystem class. You can use the code res(“<propertyname>“).ToString, where <propertyname> is the name of a valid Win32_OperatingSystem property. This begs the question, “OK, so what are the valid property names?” Luckily, there is good documentation on msdn.microsoft.com. See this link for a list of the Win32_OperatingSystem properties: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/win32_operatingsystem.asp.

As well as retrieving information about Windows, WMI can be used to programmatically control Windows. For example, the following console application will log off the current user:

Imports System.Management
Module Module1
Sub Main()
Dim mgs As ManagementScope
mgs = New ManagementScope("\\LocalHost\root\cimv2")
mgs.Options.EnablePrivileges = True
Dim qry As ObjectQuery
qry = New ObjectQuery("SELECT * FROM Win32_OperatingSystem")
Dim sch As ManagementObjectSearcher
sch = New ManagementObjectSearcher(mgs, qry)
Dim res As ManagementObject
Dim resColl As ManagementObjectCollection = sch.Get
‘These two numbers are parameters, they mean LogOff without
‘rebooting. For a complete list of parameter types, see
‘http://msdn.microsoft.com/library/en-us/wmisdk
‘/wmi/win32shutdown_method_in_class_win32_operatingsystem.asp
Dim strArgs() As String = {"0", "0"}
For Each res In resColl
res.InvokeMethod("Win32Shutdown", strArgs)
Next
End Sub
End Module

Complete documentation for WMI is available at this link: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/wmi_reference.asp . WMI methods are located in the System.Management namespace.

end sidebar




Security for Microsoft Visual Basic  .NET
Security for Microsoft Visual Basic .NET
ISBN: 735619190
EAN: N/A
Year: 2003
Pages: 168

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net