16.2. InfoPath Security

InfoPath has its own built-in security model that is exposed to developers to allow them to start with some in-place baseline security and then customize it according to their needs. InfoPath's security model is different from most; it uses some settings from Internet Explorer as well as some of the .NET security model. InfoPath works closely with Internet Explorer's security model to closely guard your local resources against malicious attacks from hackers

InfoPath is a client-side application, meaning it runs on your local machine. Because of being a client-side application, it is not allowed to do certain things to your machine, for example, reformat your hard drive. It must obey all security laws that regulate your machine. This allows the user of the forms to feel assured that InfoPath or your custom-built form will not violate any security issues. Realize that InfoPath, as a data-driven type of application, provides additional levels of security to protect the data that is coming in and out of the custom-built InfoPath form.

The default behavior of InfoPath is to use Uniform Resource Locator (URL ) based forms; the second behavior is to use Uniform Resource Names (URN ) based forms. These types of forms may look, act, and feel the same, but there are some significant differences in the two models.

URL-based forms are the default form type used with InfoPath. These forms are created by publishing a form to a Web server, a Microsoft SharePoint site, or file share. They are called URL-based because typically a user will open these InfoPath forms by using a URL pointing to the location of the published form. URL-based forms are considered "sandboxed" forms. A sandbox is a location on your computer that is controlled highly by IE's security settings, in particular, the zones discussed in the next paragraph.

Internet Explorers security is based on the Zones theory. There are five zones in the IE model, with 1 being the most restrictive and 5 being the least: Restricted, Internet, Intranet, Trusted Sites, and the Local Machine zone. You can see the icons in Figure 16-1.

For example, if a Web page you visit has a script that tries to create an unsafe ActiveX control, it will cause an error on every zone except Local Machine and Trusted Sites, which will prompt you first.

Local Machine is not listed in the choices in Figure 16-1 because everything on your local machine is trusted.

Consider another example. Just as InfoPath forms can use scripts you create, other applications, such as those created in HTML, use script as well. If an application that uses script tries to call a resource on another domain, you will get the following Access Is Denied message: "This page is accessing information that is not under its control. This poses a security risk. Do you want to continue?" This dialog box will appear if you are in the Intranet Zone, but in the Local Computer or a Trusted Site zone your script will run just fine. Script in InfoPath's HTML task pane is subject to these rules as well.

16.2.1. Form-Based Security

As shown in Chapter 9, "Managing Views," you can run script in the HTML custom task pane of InfoPath. In Chapters 11, 12, and 13 you saw how to create scripts in InfoPath forms as custom business logic, for example, scripting the On Load event of the form or the On Click event of a control Each property or method used from the InfoPath object model has its own security measures. These models are numbered 1 to 3:

• Level 1: Properties and methods can be called by anyone. These are methods that are considered safe no matter who or what calls them.

• Level 2: InfoPath forms can communicate with each other. For example, you can write the following and get access to another form running on the machine:

  Application.XDocuments.Item(1)

  
  

  Whether this works or not is based solely on where the .xsn file is located. Most of InfoPath's Object Model resides in this zone.

• Level 3: These calls are considered unsafe no matter who is calling them. The only way to call these methods is to use Full Trust on the form. This means that you must register the form or digitally sign the form. You also can use the regform.exe utility to register the form with full trust for you.

InfoPath's default security model restricts all access to local system resources and is not allowed to use components that are not built to be safe for scripting.

Form templates (*.xsn) files based on a URL are thrown into what is commonly known as a sandbox. As mentioned in the last section, the sandbox model means that the form is thrown into a local system cache that inherits its security from Internet Explorers security settings, as shown in the following Try It Out.

16.2.1.1. Try It Out: Looking at IE's Security Settings

Usually InfoPath forms run in the Local intranet zone of IE, using permissions that you set for that particular zone. You can see those permissions in Figure 16-2.

Remember that InfoPath security is based on the location of the .xsn form template, not the client location. You will need to keep that in mind as you are developing the InfoPath forms. This means that any local resources to which you allow permission on your machine will and can be accessed by InfoPath over the network from other machines. So, if you give access to a resource just as specific folders on your machine, other users will be able to access that folder on your machine. This is not good in most cases.

16.2.2. Fully Trusted Forms

It's possible to allow InfoPath forms to run in a fully trusted context. The InfoPath form needs to be installed locally and then given access to local system resources. Fully trusted forms have more privileges on a local machine than cached or sandboxed forms. Being trusted on your system allows the InfoPath to access:

• Objects external to the InfoPath form but on the same system

• Microsoft ActiveX controls that are marked safe for scripting

• Custom logic within the Component Object Model (COM ) and additional object models

The higher the trust level the more resources the InfoPath form has access to. For this reason, the next Try It Out shows you how to create fully trusted form on your machine.

16.2.2.1. Try It Out: How to Create a Fully Trusted Form

The first step in creating a fully trusted form is to make sure the InfoPath IDE has an option checked.

Once there you can also view all of your trusted publishers by clicking the Trusted Publishers button. This dialog box shows you what particular publishers you give full access to, as shown in Figure 16-4.

16.2.2.2. Using the SDK Regform Utility

Although you can manually create a fully trusted form, it is not good practice because there are too many little details that all need to be in place for it to work correctly. Microsoft realized quickly that this would be the case so they packaged a nice little utility for us called RegForm. This utility is included in the InfoPath 2003 Software Development Kit (SDK).

http://www.microsoft.com/downloads/details.aspx?FamilyId=351F0616-93AA-4FE8-9238-D702F1BFBAB4&displaylang=en

Once you install the SDK, you can find the RegForm utility at C:Program FilesMicrosoft Office 2003 Developer ResourcesMicrosoft Office InfoPath 2003 SDKTools, wherever you installed the SDK.

regform.exe is a command-line tool that simplifies the creation of fully trusted forms by automatically:

• Making a backup copy of your form template

• Making the necessary changes to the .xsf file and XML template files to make them fully trusted

• Updating the version of the form template

• Repackaging the files into an .xsn file template

• Creating a custom installation program

Imagine what a pain this would be to have to do all of that yourself. The RegForm parameters are very straightforward, as shown in the help display of the tool:

Usage:

RegForm [/U urn] [/FT formtemplatename] [/C companyname]
 [/V [0-9999.0-9999.0-9999.0-9999]] [/T Yes|No] [/O outputfile]

 [/MSI] [/?|/h|/help] formtemplatefile

The following options can be seen in the command window by typing:

RegForm /?

Option	Description
/U	The URN to use for the form template. Must be in the form of "urn:<string>:<string>". If the URN is not specified, it is built using the specified form template and company name parameters. If the form template or company name parameters are not specified, a GUID value is used.
/FT	The form template name.
/C	The company name.
/V	The version number [0-9999.0-9999.0-9999.0-9999] of the form template. If the version number is not specified, the version number of the specified form template file is used. If no version number is present in the form template file, the default version number "1.0.0.1" is used.
/T	Specifies that the form template is fully trusted. This sets the requireFullTrust attribute in the form definition (.xsf) file to Yes. The default value is No.
/O	The path and name of the output installation file that is to be created. If the path and name are not specified, the name of the form template file is used.
/MSI	Specifies that the output installation file is a Microsoft System Installer (.msi) file. The default is a Microsoft JScript (.js) file.
/?|/h|/help	Displays information about using the RegForm tool.
formtemplatefile	The full path to the InfoPath form template to process.

Examples:

RegForm /U urn:MyForm:MyCompany /T Yes /MSI MyForm.xsn

RegForm /FT myForm /C myCompany /MSI myForm.xsn

Creating a fully trusted form this way is very simple:

Regform /U urn:FormName:CompanyName /T Yes C:DirectoryFormName.xsn

Using the tool this way, the /T indicates that the form should be fully trusted, and the last parameter is the path of the form to be converted to fully trusted. If you have Visual Studio .NET installed on the local machine, then you can also create an .MSI installation program using the /MSI switch:

Regform /U urn:FormName:CompanyName /T Yes /MSI C:DirectoryFormName.xsn

This will place an .msi file in the forms directory containing the setup files needed, as well as create a Visual Studio solution file for you to modify. Using Visual Studio to create a custom installation program was discussed in the "Distributing InfoPath .NET applications" section of Chapter 13, "Working with .NET Managed Code."

To get some experience with the RegForm utility, work through the following Try It Out.

16.2.2.3. Try It Out: Creating a Fully Trusted Form Using the RegForm Utility

Start by creating a fully trusted form using an existing InfoPath template, and then save the form. For the purpose of these instructions, Chapter 16.xsn will be used.

16.2.2.4. How It Works

The Chapter 16.xsn form is now fully trusted by InfoPath and Internet Explorer. This will also result in the RegForm utility creating a Chapter 16.bak file, and a Chapter 16.js file in the directory that the original template is located in, as shown in Figure 16-6.

The .bak file is a backup copy of the original template but without full trust, and the .js file is a script run on machines where the form will be installed. To have this be fully trusted on another person's machine, you must send the *.js file, and that person must run it by double-clicking it. This script sets the permissions on that person's machine. When the file is double-clicked, the user receives the dialog box shown in Figure 16-7.

16.2.3. Creating an MSI to Automatically Set Up Full Trust

If you have Visual Studio .NET 2003 installed on your local system, you are allowed to specify the /MSI attribute when using the RegForm utility. This causes Visual Studio to create an MSI setup project, discussed in Chapter 13, based on your form template. This will result in creating a Windows installer package. The following Try It Out walks you through using the /MSI attribute.

16.2.4.1. Try It Out: Use the RegForm Utility to Create an MSI

Using the command window navigate to the regform.exe folder as in the last Try It Out:

Distributing the .msi file to clients will allow them to set up the InfoPath form on another machine and create the fully trusted form for you.

One of the exciting parts about using the /MSI switch is that in your users' temporary directory under the RegForm directory you will find a Visual Studio setup solution ready for you to open up in Visual Studio and modify as you wish. This allows for more control over the setup process on the users' local machines.

Navigating to your user temp directory can sometimes be difficult as it is hidden away for obvious reasons. The best way to figure out how to get to your user's temp directory is to open up the command line and type cd %temp%.

This will navigate to the directory where the temp RegForm directory lives. Usually it is C:Document and settingsuserLocal SettingsRegForm. You are encouraged to navigate to that directory and discover what and why files are placed in that location.

This solution can be modified as you wish then recompiled to create your custom .msi file for distributing your fully trusted form.