Form Security

Before delving into the specifics of how the InfoPath event-driven programming model works, you need to understand how the security model works.

InfoPath was designed to be "secure by default" to provide protection for the end users using InfoPath to fill out your forms. As an InfoPath developer, the burden is on you to ensure that your form can be deployed without problems. The method of deployment you choose can affect which parts of the InfoPath object model your code will be allowed to use. To understand how the method of deployment you choose can affect decisions during form development, take a look at the InfoPath security model.

Form Security Levels

InfoPath defines three security levels: restricted, domain, and full trust. Each InfoPath form requires and is granted a certain level. If the granted level is lower than the required level, the form will not run. This security system is enforced regardless of whether there is code behind the form.

Forms in the restricted security level can access only resources within the form template itself. A form that requires this security level must not attempt to access local files, for example.

Forms in the domain security level can use files and connect to resources on the machine hosting the form without asking the user. If a form in the domain security level attempts to read or write information from a different machine, InfoPath prompts the user to ensure that the cross-domain access is acceptable.

Forms in the full-trust security level have complete and unrestricted access to every resource that the user running the form has access to. Only forms installed to trusted locations or digitally signed with a trusted signature are fully trusted. (Deployment location and security are discussed later in this chapter.)

When running a form, you can see whether it was granted restricted, domain, or full-trust security level by looking at the icon in the status bar, as shown in Figure 12.5.

Figure 12.5. The form's security level and location are shown in the status bar when a user fills out a form. The icons shown are for the restricted, domain, and full-trust security levels, respectively.

Automatically and Manually Setting the Required Security Level

InfoPath 2003 Service Pack 1 automatically sets the required security level as you design your form. It can do so by determining which features the form uses and the minimum security level the form needs to function properly.

If a form on the local intranet (\\MyComputer\MyShare\Template1.xsn) posts to a Web server on the Internet (www.contoso.com), for example, that is potentially dangerous. A malicious form might be attempting to trick you into entering sensitive information that would then be sent across the Internet. The form would require at a minimum the domain security level, not the restricted security level. If a user runs this form without sufficient evidence for InfoPath to grant the form the domain security level, the form will not run. Even the form it is granted the domain security level, at runtime, InfoPath warns the user when the form attempts to post the information to the new domain.

Note

InfoPath can determine the required security level automatically by looking at the properties of the form, but it does not look at the code behind the form and, therefore, might set the required security level too low. If you deploy a form that successfully requests domain trust but calls XDocument.SaveAs in an event handler, for example, the form will load but will fail at runtime if the event handler is called. In this case, InfoPath shows an error to the end user, explaining that there is not sufficient permission to perform the operation.

To change the required security level of an InfoPath form manually, open the form template in design mode. Select Form Options from the Tools menu, and click the Security tab of the Form Options dialog box, as shown in Figure 12.6.

Figure 12.6. Specifying the required security level for a form.

Deployment Location and Security

You have many options when deploying forms, and covering them completely is beyond the scope of this chapter. For the purposes of this chapter, we discuss only the impact of deployment location on security level.

You can deploy a form in two ways: the URL and the URN. URL deployment is used by default when you use Save or Save As from the InfoPath designer. Use URL deployment to publish the form to some shared location, such as a Web server, SharePoint site, or shared network directory.

InfoPath uses Internet Explorer security settings to determine what security level to grant to URL-deployed forms. If Internet Explorer would classify the form's location as an Internet or local intranet site, InfoPath will grant the form the restricted security level. If Internet Explorer thinks that the form's location is a "trusted site" or the "my computer" domain, InfoPath will grant the domain security level. Forms from locations on Internet Explorer's "restricted sites" list are not allowed to run at all.

URN deployment is necessary (but not sufficient) to ensure that InfoPath grants a form full trust. Choose Publish from the File menu of InfoPath to deploy a form to a URN. A URN-published form can be installed to the local machine or digitally signed with a trusted certificate to ensure that InfoPath fully trusts the form.

Registering a Form Template to Grant Full Trust

After you have published a form using URN deployment, the easiest way to enable a form template to be granted full trust on your machine is to call the RegisterSolution method on the form. If called from within an InfoPath form itself, this would require the full trust security level. This presents somewhat of a chicken-and-egg problem: We need to be fully trusted to register a template as fully trusted.

Fortunately, InfoPath can be automated from an automation executable, much as we automated Word and Excel in Chapter 2, "Introduction to Office Solutions." We use automation to call the RegisterSolution method; because it is not an InfoPath form calling the method, but a fully trusted utility program, there is no chicken-and-egg problem.

Suppose that we have a mortgage application form template that we want to be a full-trust form template while we are developing and debugging it. There are two ways to register the form template: We can register the .XSF file or the .XSN file.

What's the difference? If you are registering the form template so that it is fully trusted on your development machine, it makes more sense just to register the .XSF file, which can be found in the InfoPath project folder. If you are registering a form template that is going to be published to a central location for end users to use, however, register the .XSN file after publishing the form.

Listing 12.1 shows a console application that registers an .XSF file so it can be granted full trust. To use this code, create a new console application, and add a reference to the InfoPath PIA.

Listing 12.1. A Console Application That Registers an .XSF File So That It Can Be Granted Full Trust

Imports System Imports System.XML Imports InfoPath = Microsoft.Office.Interop.InfoPath Module Module1   Sub Main()     Const xsfLocation As String = _       "C:\InfoPathProjects\MortgageApplication\manifest.xsf"     ' Remove the publishUrl     Dim xsfDom As XmlDocument = New XmlDocument()     xsfDom.PreserveWhitespace = True     xsfDom.Load(xsfLocation)     Dim xns As XmlNamespaceManager = _       New XmlNamespaceManager(New NameTable())     xns.AddNamespace("xsf", xsfDom.DocumentElement.NamespaceURI)     Dim xDoc As XmlNode = xsfDom.SelectSingleNode( _       "/xsf:xDocumentClass", xns)     xDoc.Attributes.RemoveNamedItem("publishUrl")     xsfDom.Save(xsfLocation)     ' Register the file     Dim ip As InfoPath.ExternalApplicationClass = _       New InfoPath.ExternalApplicationClass()     ip.RegisterSolution(xsfLocation, "overwrite")   End Sub End Module 

When you are registering an InfoPath form to be fully trusted, the form must not have a publishUrl. A publishUrl means that the solution is URL-based. Remember that URN-based solutions cannot have a URL component and also be granted full trust. The console application in Listing 12.1 removes the publishUrl (if it exists) from the .XSF form template definition and then registers the .XSF file to enable this form to run with full-trust permissions on your machine.

Do not forget to select the Full Trust option in the Security tab of the Form Options dialog box when designing the form on which you are going to run this console application. After you have run the console application, running the form in full trust is as easy as double-clicking the manifest.xsf file.

More Information

A full discussion of the InfoPath security model and deployment system is beyond the scope of this book. For more information, refer to the InfoPath SDK documents titled "Security Guidelines for Developing InfoPath Forms" and "Form Security Model," available on MSDN at http://msdn.microsoft.com/library/en-us/ipsdk/html/ipsdkSecureAForm_HV01083590.asp and http://msdn.microsoft.com/library/en-us/ipsdk/html/ipsdkFormSecurityModel_HV01083562.asp.

For more information about digitally signing your form template, see the InfoPath Team Blog at http://blogs.msdn.com/infopath/archive/2004/05/10/129216.aspx. The InfoPath SDK, also available on MSDN, discusses using the RegForm tool to help form designers create installable form templates.