Controlling Access to a Web Service

Controlling access to a Web service is very important. Without security, a Web service is vulnerable to many types of network-related security threats, such as distributed denial-of-service (DDoS) attacks. Controlling access to a Web service involves specifying the following two pieces of information:

• The IP address / hostname of the execution target that hosts the thin-client application. This target, called the application host, is the location from which clients download and execute copies of the thin-client application. If you do not specify this information, clients who execute the thin-client application will not be able to connect to the Web service, so the application will not work for them.

  Note  The IP address / hostname of the client that downloads the thin-client application is unimportant. Again, what matters is the IP address / hostname of the application host.

• Which parts of the Web service that authorized application hosts (as specified in the first piece of information) can access.

Note  You do not need to create a clientaccesspolicy.xml file for web services you create in LabVIEW 2010 or later. When you create web services in LabVIEW 2010 or later, LabVIEW automatically adds the appropriate policy files to the system.

You specify both pieces of information by creating a special XML file, naming this file clientaccesspolicy.xml, and placing this file in the root directory of the Web service host. When a thin-client application attempts to connect to the Web service, the application first checks for the existence of this file. If the file exists, the application checks the contents of the file to see what, if anything, this file allows the application to access.

Refer to this topic for an overview of the roles the application host, Web service, and clients play in using the LabVIEW Web UI Builder.

Creating a clientaccesspolicy.xml File

The clientaccesspolicy.xml file is a text file. You can use any text editor to create and save this file as long as the XML is valid and well-formed. The following XML code shows a sample clientaccesspolicy.xml file. You can copy this code and paste it into a text editor to use as a starting point.

<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*" http-methods="*">
         <domain uri="http://*" />
         <domain uri="https://*" />
       </allow-from>
       <grant-to>
          <resource path="/" include-subpaths="true" />
       </grant-to>
     </policy>
   </cross-domain-access>
</access-policy>

The following list provides information about the tags used above:

• policy—This tag defines a policy. You can define more than one policy in a single clientaccesspolicy.xml file.
• allow-from, domain—These tags specify the IP addresses / hostnames of execution targets that can connect to the Web service. To access the Web service, a Microsoft Silverlight application, such as the Web UI Builder editor or the thin-client application you build, must be hosted at an address specified in these tags. If you customize these tags, keep the following requirements in mind:
  • While you are building the VI, *.niwsc.com needs to be in this list so the Web UI Builder can connect to the Web service and generate an API for it. You can remove *.niwsc.com from this list after you deploy the thin-client application.
  • After you deploy the thin-client application, the IP address of the application host must be in this list. Otherwise, clients who download the application will not be able to connect to the Web service. Exception: Thin-client applications hosted on the Web service host do not need to be in this list. Therefore, if the application host and the Web service host are the same execution target, the IP address of the application host does not need to be in this list.

    Note  The asterisk serves as a wildcard. For example, <domain uri="*" /> means that a thin-client application hosted at any IP address can access the Web service. This entry is useful for testing purposes because it eliminates the possibility that the clientaccesspolicy.xml file is causing a connection problem.

• grant-to, resource—These tags specify the paths to the Web service and any subpaths that authorized applications can access. In the example file above, notice that the IP address / hostname is not specified. Leaving this information out means you can enter either the IP address or the hostname in the Import Web Service dialog box in the Web UI Builder.
  
  The argument include-subpaths="true" specifies that clients can access all subpaths of the given path. This argument is useful because it means you can grant access to multiple subpaths without having to specify each subpath individually. If you set include-subpaths to "false", which is the default value, clients cannot access any subpaths. You then must define specific resources by using additional <resource/> tags.

  Note  Asterisks do not work as wildcards with these tags. Instead, use a forward slash (/) with include-subpaths to represent a top-level folder and everything underneath it. For example, <resource path="/" include-subpaths="true" /> means that authorized Silverlight applications can access any Web service on the host. Again, this entry is useful for testing purposes.

Transferring the clientaccesspolicy.xml File to the Web Service Host

After you create the clientaccesspolicy.xml file, you must transfer this file to the Web service host. You have the following two options for transferring this file to the Web service host:

• If the Web service host is a real-time target, such as a CompactRIO or PXI controller, use an FTP program, such as Filezilla, to transfer the file to the web service host. The file must reside in the ni-rt/system/www/ directory.
• If the Web service host is a desktop PC, transfer the file by any means, such as a USB drive. The file must reside in the Root directory of the LabVIEW Web server. By default, this directory is labview\www\, where labview is the installed location of LabVIEW on disk. Complete the following steps to see the actual directory:
  1. Launch LabVIEW.
  2. Select Tools»Options.
  3. Select Web Server from the Category list. LabVIEW displays Web server options on the right side of the dialog box.
  4. Locate the Root directory path in the Basic Settings section. You must place the clientaccesspolicy.xml file in this directory.