Data Connections in Browser Forms

A while back, I wrote a series of 3 blog posts about authentication that was targeted at advanced enterprise-level scenarios involving multi-tier delegation of credentials for data connections on the server. However, I never took the time to cover the basic scenarios around getting basic data connections to work on the server. This post will answer the question "how do I get my data connection to work on the server". Cart, meet horse.

When we started defining the server experience for InfoPath forms, one of the guiding principles we espoused was "design-once." Meaning, provided you stick within the subset of functionality supported on the server, you could design a form once and it would run in InfoPath and in Forms Services. That is basically true for data connections, but there are two special considerations that differ significantly when moving to the server, namely

Authorization to perform cross-domain connections
Multi-tier authentication

The cross-domain issue, server edition

Short version:

You can’t make a cross-domain connection from a domain security browser form unless your data connection uses a UDC file. Period.

Long version:

InfoPath has three security modes, which we refer to as restricted (AKA "super-sandbox"), domain, and full-trust. Restricted form templates don’t run on the server. Full-trust form templates are allowed to do whatever and consequently need to be administrator-approved in order to run server-side. Domain trust form templates constitute the vast majority of form templates in the enterprise, and roughly follow the Internet Explorer security model which dictates that by default, the user must approve any attempt to access resources that come from a different domain or Zone. So, if you have a form template running on http://myserver/, and it tries to connect to a web service on http://yourserver/, InfoPath will prompt you before trying the connection.

Works great in InfoPath, but when you run a form in the browser, you may be running server-side business logic. That business logic may want to execute a data query. Because HTTP is a stateless protocol, Forms Services can’t halt execution of a server-side process and return to the browser in order to ask you for permission to continue. Additionally, the user in this case may not be the right person to own the decision about whether the cross-domain connection can take place. So, this decision is placed instead in the hands of the server administrator who owns security around the form template. Depending on whether the form is administrator-approved or just published to a document library by Joe User, this ownership falls on the farm administrator (I call her Julie) or the site collection administrator (henceforth known as Bob).

The technology which allows Julie and Bob to determine whether forms can make cross-domain connections involves a system of checks and balances. Central to this system is a data connection settings file in the Universal Data Connection V2 format, called a UDC file. Bob’s UDC files live in a special type of document library called a Data Connection Library, or DCL. Julie’s UDC files live in the Microsoft Office SharePoint Server configuration database, and are managed via the "Manage Data Connection Files" page in the Application Management section of SharePoint Central Administration (I tend to refer to this as "the store").

The basic premise behind UDC files is that in InfoPath 2007 your data connection settings can live outside of the form template in one of these files, and both InfoPath and Forms Services will retrieve the current connection settings from this file at runtime before making the connection. The UDC file itself is retrieved from a URL relative to the root of the site collection where the form was opened. This enables lots of cool functionality - for example, you can now share settings across multiple forms and change them once when you move your data source.

You can also pre-deploy test and production versions of your data connection settings to your staging and production environments so that you don’t need to update the form template with new data connection settings when you go live.

For the purposes of this discussion the key takeaway is that a domain security form running in the browser will never make a cross-domain data connection unless those connection settings come from a UDC file.

In other words, you can’t make a cross-domain connection from a domain security browser form unless your data connection uses a UDC file. Period.

Why is this more secure? Well, if Bob is a good administrator, he controls access to Data Connection Libraries on his site collection. A DCL requires content approval by default, and while members of the site with Contributor access can write files to the library, nobody but the owner of the file can use the file from InfoPath unless a content approver has approved the file. By default, all members with Designer permissions have the Content Approval right. In short, Bob can set up the site collection such that only people that he designates can approve UDC files. Therefore, forms on Bob’s site collection can only make connections outside the farm unless he approves the connection first.

Julie’s central store is more secure - only users with access to SharePoint Central Administration can modify those files. Furthermore, by default only the server object model can access files in the store. In order to make these files accessible to web clients such as InfoPath, the "web accessible" flag must be set. Otherwise, the files can be used from browser forms only.

Finally, if Julie wants to have complete control over cross-domain connections for the farm, she can turn off the ability for user form templates to make cross-domain connections at all (in fact, these are disabled in a default install). When cross-domain connections are disabled for the farm, even connections that use settings from a UDC file can’t make cross-domain connections.

Solving multi-tier authentication issues

Once your form is allowed to make cross-domain connections, you’ll need to deal with getting access to the data. If your data lives on a different computer than your Forms Services site, this means figuring out an alternative set of credentials for data access. I’ve covered why this is true, and the various options for accomplishing this task, in a series of posts called "Advanced server-side authentication for data connections," but I left out one useful prototyping trick. Consider the following UDC authentication block:

<udc:Authentication>
       <udc:UseExplicit CredentialType="NTLM">
              <udc:UserId>myusername</udc:UserId>
              <udc:Password>mypassword</udc:Password>
       </udc:UseExplicit>
</udc:Authentication>

The UseExplicit element allows you to specify a username and password in plaintext. When this is present, Forms Services will impersonate the specified user using the supplied credentials. This is a great tool for prototyping - you can see immediately whether your connection can be made given valid credentials before you go to the trouble of setting up Office Single Sign-on. However, I cannot stress enough that this is for prototyping only. Because the UDC file is in clear text and is accessible to anyone with read permission on the library, this puts a windows username and password in clear text on the network, which is bad-bad-bad. You’ve been warned.

Whatever Julie wants, Julie gets

The "Manage data connection files" page (AKA "the store") gives Julie a great deal of power over the use of data connections in administrator-approved form templates. Furthermore, Julie also has a great deal of control over what Bob’s users can do. The following defaults can only be modified on the Configure forms services page:

User form templates cannot make cross-domain connections (not even with a UDC files)
User form templates cannot use authentication embedded in a database connection string.
User form templates cannot use the authentication section of the UDC file
User form templates can use credentialType BASIC or DIGEST only if the connection is made using SSL.
User form templates cannot make cross-domain connections (not even with a UDC files)
User form templates cannot use authentication embedded in a database connection string.
User form templates cannot use the authentication section of the UDC file
User form templates can use credentialType BASIC or DIGEST only if the connection is made using SSL.

The following default setting can only be modified on the Configure Web Service Proxy page:

User form templates cannot use the Web service proxy

What’s next?

Now that you’re motivated to use UDC files to enable data connections on the server, you’ll need to know how to create them and how to re-use them. I’ll tackle that topic in a future post.

- Nick Dallett

Program Manager