InfoPath has built-in mechanisms to limit the amount of trust that you can apply to a form. There are three security levels: restricted, domain, and full. These security levels control what the form can and cannot do.
In the restricted security level the form can't access data outside of the form itself. In other words, all the integration with the environment (with the exception of email submission) is disabled. This level of security is not supported for Forms Server templates; they're promoted automatically to the domain level of security. When you add an email data connection for submission, InfoPath will automatically set the form to a restrictedsecurity level.
Domain-level security allows access to the data sources in the same domain, on the local computer, and in the local intranet zone as specified in Microsoft Internet Explorer. It's limited to utilizing built-in integration functions and some lower-level code only. Sure, forms with domain-level security can run code, but only certain methods. The article "About the Security Model for Managed Code Form Templates" (from "InfoPath Developer Reference for Managed Code" MSDN, 2007) describes in general which objects and methods are available for domain-level trust forms.
The highest level of trust, full trust, is necessary when the code in the form needs unrestricted access to the API. If you think about it, after you're running some code, it's possible to do nearly everything to the computer, including things that a form shouldn't be able to do. However, fulltrust requires that the form is signed either with a code-signing certificate or installed on the computer. For a workstation this publishing happens through a standard Microsoft Windows Installer MSI file. On a Forms Server it's published as an administrator-approved form template.
Code signing works by indicating the verified author of the form. This technique allows the user to decide whether or not to run the form. The code-signing process relies on a trust hierarchy and a secure hash. The trust hierarchy basically means that there is a set of trusted certificate authorities; these are authorities that you believe will tell you the accurate identity of a certificate holder. Microsoft provides a set of trusted authentication providers out of the box; these are organizations that Microsoft believes you should trust to provide accurate verification of the people they issue certificates to. In addition, if you're a member of a domain and there is an enterprise certificate authority, you'll also trust the domain's enterprise certificate authority.
This trust hierarchy is coupled with a secure hash, which can be recalculated by every computer. The hash is calculated by the signer and then encrypted with its private key. The signer then attaches a copy of its certificate that includes its public key. The certificate itself includes the hierarchy of servers that issued the certificate. The recipient computer calculates the hash for the document and decrypts the hash in the document with the public key from the certificate. If the keys match, then the owner of the certificate—issued by a trusted source—is indeed the person who signed the code. This approach means that if you trust the person or organization that was issued the certificate, you should trust that the code came from them.
Code-signing certificates aren't difficult to obtain, and you can purchase them from one of the trusted root certificate authorities. Or, if you're in an organization with an active directory domain, you can issue one yourself. (You can read step-by-step instructions on how to issue a certificate in the blog post "Domain Certificate Authority Signing InfoPath 2007 Forms.")
Approved Form Templates
Administrator-approved form templates are templates that have been published by the administrator of a Forms Services computer. The administrator of the server has specifically decided these forms are appropriate for users of the Forms Services server. Because there is a trusted person—namely, the administrator specifically approving form templates published to the Forms Services server—using InfoPath form templates with attached code doesn't require being signed. However, this practice is a good idea given that the administrator knows who the form came from and that he or she is authorized to ask for the deployment of the form.
The process for publishing an administrative form isn't particularly difficult; however, these forms do require access to central administration to complete—access that only a handful of users will have. After they are published, these administrator-approved form templates can be activated in any site collection on any web application in the farm.
Deciding how to add code to your InfoPath form (or for that matter whether it's right to put code in the InfoPath form) isn't as straightforward as it might seem at first. The simple options of script or .NET code rapidly branch into an array of options that leaves no stone unturned. Whether you choose VSTA or VSTO, the 2003 Object Model, or the 2007 Object Model, you'll at least know the basics of what your decision means both in terms of what you can and cannot do.