Security Levels, E-Mail Deployment, and Mobile Form Templates [InfoPath 2003 SDK Documentation]

Applies to:

Microsoft Office InfoPath 2003 Service Pack 1

See Deploying Signed Form Templates for additional information relevant to this topic.

In Microsoft Office InfoPath 2003 Service Pack 1, additional security features and deployment functionality have been added to form templates. Support has been added to allow form templates to be moved from one location to another or sent as an attachment to an e-mail message. In addition, support has been added to the InfoPath design mode to facilitate the creation and deployment of fully trusted forms.

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

• Custom Task Pane
• Data Connections (except e-mail submit)
• ActiveX Controls
• Managed Code
• Roles
• Workflow

Domain

Full Trust

requireFullTrust

Note  All forms generated in the InfoPath designer have a security level associated with them. InfoPath will attempt to open 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 was opened.

Trust Levels

The highest level of trust that can be granted to a form template is determined by the "cached from" location (that is, where the form is cached from) and other verification code, as described in the following table. The attributes listed in the table (for example, HTTP, UNC, requireFullTrust) are cache-based entries that are used to determine the level of trust that can be granted to a form.

Form Open Behavior

All form files opened in the InfoPath editor are bound by a set of conditions that determine the security level in 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 the "Insufficient Security Privilege Warning" 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.

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 doing the following:

• Select Form Options from the Tools menu.
• In the Form Options dialog box, select the Security tab.
• Deselect the Automatically determine security level check box.
• Select the desired security level.

Mail Deployment and Mobile Form Templates

Microsoft Office InfoPath 2003 Service Pack 1 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.

Understanding form identity

Form ID

namename="urn:MyForm:MyCompany:Template1:myXSD-1583-78-G3V94-23-47"

Access Path

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, 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

1. From the File menu, click Send Form as Attachment. (You will be required to save the form template at least once before doing this.)
2. Populate the To: line of the e-mail message.
3. Send the e-mail message.

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

E-mail deployment of Restricted form templates in InfoPath Service Pack 1 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.

Form templates with the Domain trust level have some of the same security restrictions they had in InfoPath 2003, but with Service Pack 1, they have some added functionality. For example, these templates still must be opened from their published location, but by using the Send Form as Attachment option in the File menu, they can now 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, allowing for a tangible form template hit target.

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.

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

• 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 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. 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, you must 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 run at the Restricted level unless they can retrieve updates from a shared location.

Compatibility

Benefits of Using Signed Form Templates

The biggest benefit of using signed form templates is that these templates can be deployed to recipients outside a firewall, whether the template requires no trust level or is signed for full trust. You can take advantage of this benefit if you want to use InfoPath forms to do surveys or collect data, for example. This benefit, along with advanced declarative functionality (such as using rules and calculations), allows you to deploy rich and dynamic forms easily.

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 Microsoft Windows SharePoint Services.
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.

When you open the form template, the form will relink and synchronize, based on the Form ID, with the one you saved on the Web site running Windows SharePoint Services in step 1.

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).

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 template has a Domain trust level and the domain does not match the href attribute of the form. This behavior is to prevent forms with form templates they were not explicitly created with from being opened.

The updated cache model in Service Pack 1 does not allow form templates with the same Form ID to coexist. Four additional registry keys have been added to help form authors give users the option of whether to allow the XML file to open against a form template. The updated 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 Microsoft Internet Explorer domain settings. These values specifically determine the form open behavior in these security zones.

The registry key path is

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

The form open behaviors are defined as follows:

• 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 the template is located in (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.

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.