Security Levels, E-Mail Deployment, and Remote Form Templates

Microsoft Office InfoPath 2007 supports moving form templates from one location to another, sending them as an attachment to an e-mail message, and creating a Microsoft Installer Package (*.msi) for installation of Full Trust form templates.

Security Levels

Form templates can have one of three different security levels, depending on where the form is located. These security levels are as follows:

Restricted

The Restricted security level does not permit any communication outside of the form template. This security level is intended to prevent harmful forms from transmitting any data from your computer to a malicious attacker. When running in this security mode, the following features will not work:

  • HTML Task Panes
  • SharePoint Query
  • SharePoint Submit
  • XML File Query
  • Database Query
  • Database Submit
  • Web Service Query
  • Web Service Submit
  • Web Server Submit
  • Custom Script Submit
  • Hosting Environment Submit
  • ActiveX Controls
  • Roles
  • SharePoint Workflow
  • HWS Workflow
  • Rules that open a New Document
  • Managed Code
  • Script
  • External Print View
  • Linked Images
  • Rich text box containing linked images

Domain

The Domain security level restricts a form to a particular Internet domain and its privileges are restricted to the Windows Internet Explorer settings for the zone where the domain is located. The form is allowed to communicate with other data inside its own domain but is typically not permitted to retrieve data from other domains unless the zone allows cross-domain communication. This is the minimum security level allowed for browser-compatible form templates.

Full Trust

The Full Trust security level allows you to run a form with full trust on the computer where the form will be used. This security level can only be used when working with a form located on a server that is signed with a signature that matches a trusted root publisher on your computer, or by installing the form. Both methods require setting the requireFullTrust attribute to "yes". By using this setting, you can access object model calls such as file save, and you can disable certain security prompts that appear when running at a more restrictive security level.

Bb251024.vs_note(en-us,office.12).gif  Note
All forms generated in the InfoPath designer have a security level associated with them. InfoPath opens forms at their associated security level. If the security level associated with the form is higher than the security level that can be granted to it, the form will not open.

The Full Trust security level can only be set for installed or signed form templates; otherwise, the maximum trust level is Domain. InfoPath will not set a security level to Full Trust automatically.

Forms are granted security levels based on the location from which the form is opened.

Trust Levels

The highest level of trust that can be granted to a form template is determined by the Opened From location and other verification code, as described in the following table. The attributes listed in the table (for example, HTTP, UNC, requireFullTrust) are entries that are used to determine the level of trust that can be granted to a form, and apply to forms opened in the InfoPath client.

Highest Level of Trust Granted Full Trust Client Computer (Sandboxed) Intranet (Sandboxed) Internet (Sandboxed) Restricted
file: Access Path=Opened From Location     X    
file: Access Path<>Opened From Location or no Access Path (regardless of where the form came from)         X
Opened From Location: Intranet HTTP or HTTPS     X    
Opened From Location: Internet HTTP or HTTPS       X  
Opened From Location: UNC     X    
Installed Template (requireFullTrust="yes") X        
Installed Template (requireFullTrust="no")   X      
Template with trusted publisher certificate X        
Extracted Form Files     X    

Form Open Behavior

All form files opened in the InfoPath editor are bound by a set of conditions that determine the security level at which the form will open and whether it will open. When an InfoPath form is opened in the editor, it will either be opened with an appropriate security level, or it will fail to load. If a form requests a higher security level than it can be granted (a form can request a specific security level using the trustLevel or requireFullTrust attribute), it will not be permitted to load. Otherwise, it will be loaded with the security level it requests. If the form template is not permitted to open with the requested security level, the user will not be able to open the form and will receive an error message.

The following table describes the conditions required for opening a form at each security level and the resultant behavior when the user attempts to open the form.

Editor Opens/Fails Full Trust (requireFullTrust="yes") Domain Trust (trustLevel="Domain" or blank) Restricted (trustLevel="Restricted")
Trusted (installed or trusted certificate) Editor opens at Full Trust level N/A N/A
Domain Trust: Client Computer Fails to open Editor opens at Domain level Editor opens at Restricted level
Domain Trust: Intranet Fails to open Editor opens at Domain level Editor opens at Restricted level
Domain Trust: Internet Fails to open Editor opens at Domain level Editor opens at Restricted level
Restricted Fails to open Fails to open Editor opens at Restricted level

Specifying a Security Level

The InfoPath designer automatically selects the appropriate security level (either Restricted or Domain) based on the features you are using in the form. The security setting is always as restrictive as possible, starting at Restricted, to help ensure a greater level of protection for you and your data. Users can manually override this automated setting to select a level of security that is more appropriate for the form by performing the following steps:

  1. On the Tools menu, click Form Options.
  2. From the Categories, click Security and Trust.
  3. Uncheck the Automatically determine security level (recommended) check box.
  4. Select the desired security level.

Mail Deployment and Mobile Form Templates

Office InfoPath 2007 allows you to send your form templates as an attachment to an e-mail message and to move them from one location to another. Mail deployment is an easy and effective way to distribute forms for interoffice use as well as to deploy forms to remote users.

Alternatively, if you have Microsoft Office Forms Server 2007 available, creating form templates that are compatible with InfoPath and InfoPath Forms Services allows users who do not have Office InfoPath 2007 installed to fill out forms. InfoPath Forms Services also allows mobile users to fill out forms while connected to the server.

Understanding form identity

All forms in the InfoPath designer are created with an identity. This identity information helps InfoPath associate forms with form templates in the cache and retrieve updates to forms when they are posted to a shared location. By default, InfoPath creates two identities for form templates: a Form ID and an Access Path.

Form ID

The Form ID is a unique identifier based on a prefix, the form name, and the form namespace. The identifier should be a unique name that can be used to correctly associate form files with the associated form template in the client computer cache. The Form ID is specified as the name attribute (for example, name="urn:MyForm:MyCompany:Template1:myXSD-1583-78-G3V94-23-47") in the form definition file (.xsf).

Access Path

The Access Path is a location identifier used to determine the correct location for the form template as well as a location to receive updates. When saved or published, the location to which the form template is saved or published becomes the default Access Path. Each time a form is opened on the client computer, the form attempts to associate itself with a cached form. It will attempt to do this in the following order:

  1. Look for a fully trusted form template with a matching Form ID.
  2. Look for a form template in the cache with a matching Access Path.
  3. Look for a form template in the cache with a matching Form ID.

Once matched, the form will open with the associated form template. In cases where the match was made with an Access Path, InfoPath will use the Access Path to retrieve updates to the form template. This method simplifies enterprise management, maintenance, and update of forms. In cases where the match cannot be made and the trust level is Domain, the form will fail to open. The Access Path is specified as the publishUrl attribute in the form definition file (.xsf).

Just as there are two identification properties for each form template, there is a set of heuristics to specifically determine the resulting entries in the cache, based on the condition of the form template (whether it has an Access Path, a Form ID, or both) and the state of the network connection.

Designing a form to send as an attachment to an e-mail message

All forms created in the InfoPath designer can be sent to users as an attachment to an e-mail message. E-mail deployment is an easy and effective way to distribute forms for interoffice use as well as to deploy forms to remote users. To mail a form template to other users, perform the following steps in design mode:

  1. From the File menu, click Publish.
  2. In the Publishing Wizard, select To a list of e-mail recipients and click Next.
  3. Click Next on the next two screens of the Publishing Wizard, then click Publish.
  4. An e-mail message will appear allowing you to fill in the list of recipients and any additional instructions you may have for them.
  5. Once you are finished, click Send. The form and the form template will be attached to the message.

E-mail deployment: Restricted, Domain, and Full Trust form templates

E-mail deployment of Restricted form templates allows dynamic forms without data connections to be opened from anywhere. Recipients can open form templates sent as e-mail attachments either directly from Microsoft Outlook or from wherever the recipient has saved the attachment. Additionally, Microsoft Office Outlook 2007 allows users to edit forms directly in the message.

Form templates with the Domain trust level must be opened from their published location, but by publishing To a list of e-mail recipients in the Publishing Wizard, they can be sent as an attachment to an e-mail message. The attachment, when opened, functions as a link to the actual published location of the template. The form template at that publish location is what is actually opened in the InfoPath editor.

Using a Domain-level form template sent as an e-mail attachment is similar to using any other type of document; for example, a Microsoft Excel workbook or a Microsoft Word document. A user can just click on the form to open and use it. In addition, all the benefits of Domain-level updates are available to users.

You can e-mail form templates that request Full Trust access, but these templates must be signed or they will not be allowed to open. Form templates requesting Domain or Restricted access do not have to be signed to be sent as an e-mail attachment. InfoPath does not check or verify the signature, even if the template is signed, except to see whether it can be updated automatically. You could digitally sign a Domain or Restricted form template and still have automatic update capability. In this case, the digital signature will prevent any cache conflict messages from appearing.

Sharing forms by e-mail message or from a common shared location

Certain questions should be considered when building a form that will be deployed by e-mail message.

  • Will your form be updated regularly? If you are developing a form that must be updated regularly, the form should be published to a shared location before it is sent to other users. This practice allows you to update the form by publishing newer versions to the shared location but it also allows you to immediately distribute the form template to users who may not have access to the shared location.

    If a form is updated and then distributed by e-mail message, users will get a cache conflict message when they try to open the new form, if they have an older version stored on their computer and the Access Path has changed. The user will be prompted to choose which version they want to use. Even if the updated form is the same as the one on the user's computer, the user will get a cache conflict message and be prompted to choose which copy they want to use. The best practice to use in the latter case is to share the form from a shared location instead.

  • Does your form access a data connection or use other features not supported at the Restricted security level? If you are developing a form that requires Domain-level security, InfoPath requires that you publish the form to a shared location in order for users to be able to open it. Because form templates will only open at the security level they request, forms opened directly from an e-mail message will fail to open if InfoPath cannot grant Domain-level security.

Benefits of Using Signed Form Templates

There are two benefits to digitally signing form templates:

  • It allows the form template to open with Full Trust security.
  • It avoids the cache conflict message if the form is moved to a new location.

Additionally, if a form template is signed, you get the added benefit of the automatic update functionality. For more information, see Deploying Signed Form Templates.

Example: Updating Domain or Restricted Templates   The following example shows how an updated, signed form template requesting either Domain or Restricted access can overwrite an older copy:

  1. "A" sends a signed form template to "B".
  2. "B" opens the form template.
  3. "A" updates the form template (for example, adds more fields).
  4. "A" sends the updated form template to "B".
  5. "B" opens the updated form template.

The result is that the updated form template overwrites the older copy.

Example: Deploying Restricted Form Templates on an Extranet  The following example shows how you can send a Restricted form template to recipients on an extranet and still be able to open it and synchronize it with a Domain form template, without prompts, when it is sent back to you. The steps are as follows:

  1. Save the Domain form template on a Web site running Windows SharePoint Services 3.0.
  2. Change the form template security level to Restricted.
  3. Save the form template on your computer desktop.
  4. Remove the URL (required only if users have access to the original publish location).
  5. Send the form to users on an extranet.
  6. Have the users install the form.
  7. Have users send the form back to you after filling it out.
  8. Save the form back to the Web site running Windows SharePoint Services 3.0 and relink the form by using the Relink documents to this Library option in the Form Library Settings page.

Signature Verification Failure

A signed form template that requests full trust access but for which the signature cannot be authenticated will fail to open. Signature verification can fail for any of the following reasons:

  • The root certificate is not in the trusted root certificate store.
  • The certificate used to sign the form template has expired.
  • The certificate used to sign the form template has been revoked.
  • The signature on the form template is corrupt (an indication that the form template was altered after it was signed).
Bb251024.vs_note(en-us,office.12).gif  Note
If a signed form template requests Domain or Restricted access, InfoPath will not check or verify the signature except to determine whether the template can be updated automatically.

Infrastructure Registry Keys for Form Migration Open Behavior

When a user attempts to open a form, and the form is matched against a form template by its Form ID, InfoPath will display an error message if the form template has a Domain trust level and the domain does not match the href attribute of the form. This prevents forms from being opened that were not explicitly created with the form template.

InfoPath does not allow form templates with the same Form ID to coexist. Four additional registry keys help system administrators give users the option of whether to allow the XML file to open against a form template. This model also allows administrators to set the open behaviors they want for forms.

The following table describes the default settings for the registry keys. If these registry keys are absent, the default value specified in the table will be enforced.

The Name values correspond to the Windows Internet Explorer domain settings. These values determine the form open behavior in these security zones, either blocking or allowing the opening of the form, or giving the user the option to open the form.

Name value Block User Interface Allow
Internet X    
Intranet   X  
Client Computer     X
Trusted Site     X

The registry key path is

  HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\InfoPath\Open Behaviors

The form open behaviors are defined as follows:

-

<table>
<tbody>
<tr class="odd">
<td><pre IsFakePre="true" xmlns="http://www.w3.org/1999/xhtml">

Block [REG_DWORD = 0

\- An error dialog with a Help button will be shown. InfoPath will not allow the XML file to open when the form is running in the specified security zone and does not match the template domain.
  • 
    
    

    User Interface [REG_DWORD = 1]

    \- The Yes/No dialog will be shown. InfoPath will prompt the user to open the XML file against the form template when the form is running in the specified security zone and does not match the template domain.
    • 
      
      

      Allow [REG_DWORD = 2]

      \- The XML file will open without an error or warning dialog. InfoPath will allow the XML file to open when the form is running in the specified security zone and does not match the template domain.

      If a form is opened against a form template running at the Domain security level, and the security domain of the template's "cached from" location (that is, where the form is cached from) and the form's href attribute do not match, InfoPath will check the registry to define the form open behavior. Allowed behaviors will be based on the security zone in which the template is located (the CachedFromLocation value).

      For example, when a form matches a form template based on Form ID but not on Access Path, and the form template is cached from an Internet location, InfoPath will show an error dialog with a Help button.

      Bb251024.vs_note(en-us,office.12).gif  Note
      InfoPath forms will not open when the domain is an Internet Explorer Restricted domain; therefore, there is no registry key for Internet Explorer Restricted Sites.