How to: Evaluate and approve a form template

  • Article

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2016-11-14

In this article:

  • About evaluating form templates

  • Factors to consider when you evaluate a form template

This article provides detailed information for administrators of a Microsoft Office SharePoint Server 2007 farm about how to evaluate an administrator-approved form template for approval. Note that this article is not intended to provide a complete list of every possible factor to consider. Depending on your environment, there might be additional considerations not listed in this article.

About evaluating form templates

If you are responsible for approving and uploading Office InfoPath 2007 form templates to a farm that uses InfoPath Forms Services, you should know how to identify potential problems with the form templates that you approve. Because form templates can contain functionality that uses resources on the server or makes connections with data sources outside the farm — for example, managed code added by the form developer — it is important to carefully evaluate how a form template might affect farm performance and security.

Office InfoPath 2007 is designed to involve an administrator in the approval workflow for form templates. If the administrator who is responsible for approving form templates does not take adequate care when approving a form template, the consequences can include:

  • Security breaches resulting in network intrusion or loss of data.

  • An adverse performance impact on the farm.

  • Failure of the form template resulting in the loss of user data.

  • Failure of the entire Office SharePoint Server farm.

For this reason, you should rigorously evaluate each administrator-approved form template before you upload the form template to the farm. Note that correctly evaluating a form template requires an understanding of form template structure and logic. For more information about Office InfoPath 2007 form templates, see InfoPath 2007 Help and How-to (https://go.microsoft.com/fwlink/?LinkId=91423&clcid=0x409).

Factors to consider when you evaluate a form template

Important factors to consider when you evaluate a form template include:

  • Managed code   Establish proper guidelines and best practices for writing code for form templates. Form templates that contain managed code must have the Domain security level or the Full Trust security level, and therefore can pose a security risk. Verify that the code in a form template is necessary for the form to function. If the desired functionality can be accomplished without the use of code, redesign the form template and set it to the most restrictive security level possible. Note that evaluating code in a form template might require developer-level skills.

    The following list provides some key factors to consider when you evaluate code in a form template.

    • .NET assemblies in the form template should be signed with strong names to help prevent malicious tampering with the assembly. For more information, see How to: Sign an Assembly with a Strong Name (https://go.microsoft.com/fwlink/?LinkId=91429&clcid=0x409).

    • Calls to access external resources, such as databases and Web services, should be carefully reviewed. Some requests to external resources might not work if Kerberos authentication has not been deployed in the farm environment. Also, data that resides on a computer in another domain might be requested and shared with users who do not have permissions to view the data.

    • Consider automating the validation of code policies for .NET assemblies by using FxCop. FxCop is a Microsoft code analysis tool that checks .NET managed code assemblies for conformance to the Microsoft .NET Framework design guidelines. For more information, see the FxCop Team Page (https://go.microsoft.com/fwlink/?LinkId=91446&clcid=0x409).

  • **Performance and capacity planning   **Form template design and usage can significantly impact the performance of the farm, and should be planned for in any production environment. If the form will be used to submit data to the farm, ensure that adequate farm capacity exists to store the data, or loss of user data may result. For more information, see Plan for performance and capacity (Office SharePoint Server).

  • Verify the form template   Before you upload the form template in the Central Administration Web site, click the Verify button on the Upload Form Template page. If you do not verify the form template manually, it will be automatically verified during the upload process. However, manual verification will return both messages and errors, whereas automatic verification will only return errors, if any. For more information about verifying and uploading a form template, see Deploy administrator-approved form templates (Office SharePoint Server).

  • Authentication   If NTLM authentication is used, consider that NTLM can only authenticate the client computer. In a scenario where the authentication token must be passed to a third resource, such as when a Web service called by the form must submit data to a database, NTLM authentication to the third resource will fail. In such a case, consider using another authentication method, such as Kerberos authentication, which is designed to pass the authentication token. Whenever possible, form templates should use data connection files in a centrally managed data connection store to make connections to external data sources. For more information about data connections, see "Data connections" later in this article.

  • Security level   Ensure that the security level of the form template is appropriate to the purpose of the form. For example, a form template that does not use data connections that require domain authentication, does not contain managed code, or does not request data from a resource on another domain, should not be configured to the Full Trust security level. For more information, see Security levels of InfoPath forms (https://go.microsoft.com/fwlink/?LinkId=91447&clcid=0x409).

  • Passwords   Verify that passwords and other authentication information are not hard-coded in the form template. Any functionality in the form template that requires authentication should be authenticated by users at the time they fill out the form, or by using authenticated data connections. Moreover, passwords should not be stored in a form template's data source, nor should they be submitted in plain text.

  • Permissions   Form template authors should restrict access to a production form template by assigning read-only permissions to form users, write access to form maintenance staff, and no access to everyone else. Even if form templates are installed to the user computers by a logon script, you can still control access to the .xsn file if the user is not running as an administrator. You can do this by granting user access to the template file as read-only.

  • Sensitive data   Office InfoPath 2007 form templates are plain-text XML documents, and should not contain any data that you do not want to expose to users. A malicious user who has read access can read the contents of an Office InfoPath 2007 XML form by using Notepad or any other text editor, circumventing any authentication logic.

  • Business logic   Office InfoPath 2007 uses the form template to store all form logic. Because users must have access to the form template to open any form that is based on that form template, they can potentially modify the form template, circumventing any restrictions that the author put in place. This means that authentication and authorization performed on the client side cannot be considered secure. To be safe, calculations and data validation must be performed on the server side.

    The following examples show ways to design a form template to use server-side calculation and authentication.

    • Do not store sensitive data in the XML file. Instead, store keys in the XML file, and perform queries that populate the rest of the data by using a database connection or a Web service. If the user is unauthorized, return an empty dataset. You can detect such a condition on the client side and show a friendly error message in the event the user is not authorized to view the form data.

    • On submittal, send the data to a Web service and perform all possible validations on the server side. For example, if you have a condition that employees are not to submit expense reports greater than $100 without specifying an approver, have the Web service process the dataset and verify that the condition is satisfied before the data is submitted.

  • Data connections   Ensure that, whenever possible, form template authors use data connection settings from data connection files stored in the centrally managed data connection store to make connections to external resources from a form template. Using centrally managed data connection files provides the following benefits:

    • Multiple forms can use the same data connection file, so you do not need to create the data connection anew for each form.

    • If the location or connection settings for an external data source change, you must update only the data connection file, not each form template.

    • The data connection file can contain alternative authentication information that can be used by the server when a user fills out a form by using a browser.

    • Forms that are filled out in a browser without a Full Trust security level can connect to a computer in another domain if all of the data connections in the form use data connection files. For more information, see Introduction to Data Connections (https://go.microsoft.com/fwlink/?LinkId=91449&clcid=0x409).

  • External dependencies   Form templates can use external resources such as data connections, Web services, databases, and document libraries. Verify that all external resources are valid and available before you make a form template available for use.

  • Information Rights Management   Information Rights Management (IRM) cannot be used to protect browser-enabled form templates.

See Also

Other Resources

Security considerations for form templates and forms
Security levels of InfoPath forms
InfoPath 2007 Help and How-to
Introduction to Data Connections
Set the required security level for a form template
Secure Coding Guidelines
FxCop Team Page
How to: Sign an Assembly with a Strong Name