About Data Connections, Authentication, and Alternate Access Mapping

Using data connections in browser-enabled InfoPath form templates introduces some potential manageability and authentication issues that you should consider. These issues can be addressed by using Universal Data Connection (UDC) files to abstract the data connection information from the form template, by using Office Single Sign-On (SSO) services to handle authentication issues in multi-tier architectures, and by using the Web service proxy available with InfoPath Forms Services.

Universal Data Connections

Windows SharePoint Services includes support for a Data Connection Library (DCL), which is a library that can contain two different types of data connections, Office Data Connection files and Universal Data Connection (UDC). Microsoft Office InfoPath 2007 uses data connections that conform to the Universal Data Connection (UDC) file schema and typically have either a *.udcx or *.xml file extension. Different data sources can be described by these UDC files, which are stored on the server and used in standard form templates and browser-enabled form templates.

Using a UDC file located in a data connection library has the following benefits:

• Form designers can configure form template data connections that will work in both the InfoPath client and InfoPath Forms Services.

• Form designers can publish a form template to multiple servers and have different data connection settings for each server without modifying the data connection information in the form template.

• Form designers can publish a domain security form template that can access data sources in a different domain.

• Administrators can redirect data connections without modifying form templates that reference the UDC file.

• Administrators can designate which connections are approved for cross-domain access.

• Administrators can publish data connections on a single server which can be shared across multiple servers.

For information on how to create a data connection library, see How to: Create and Use a Data Connection Library. Form templates are always designed against UDC files in a data connection library, but the connection can be configured to use a centrally-managed version of the UDC file. These centrally-managed UDC files are uploaded by a server administrator. To centrally manage UDC files, browse to the Application Management page of the SharePoint Central Administration site and click the Manage data connection files link in the InfoPath Forms Services section.

When the UDC file is uploaded by the administrator, configure data connections to use the Centrally managed connection library option available by selecting a data connection in the Data Connection Wizard and then clicking the Connection Options button.

Supported Data Sources

UDC files can describe different data sources because, unlike previous Office Data Connection files, they support a wider variety of data sources. However, while most data sources that can be configured in an InfoPath form template are supported, there are some data connection types, like e-mail submit, that cannot be described in a UDC file.

Allowed data sources include:

• Microsoft SQL Server Database query

• Web service query or submit

• XML file query (XML file located on a remote server)

• SharePoint library submit

• SharePoint list query

• Web server submit (HTTP post)

Data Connection Authentication

While forms opened in InfoPath can communicate directly with the data sources configured for the form template, forms opened in the browser communicate directly with the server running InfoPath Forms Services, either a single server or a Web front end. This introduces what is commonly referred to as the double hop problem. The double hop problem, or more precisely the multi-hop delegation problem, represents an authentication issue where credentials that are needed for access to resources on a third computer, or third tier, cannot be used in the request for those resources from the second tier.

For example, a form in the browser (the first tier) communicates with a server running InfoPath Forms Services (the second tier), which in turn needs to access resources on database server or network share (the third tier). The primary security token that was used between the browser and the server running InfoPath Forms Services cannot be passed to the database server due to delegation restrictions inherent to the NTLM authentication system used by Microsoft Windows between the browser and the InfoPath Forms Services server.

You will see this problem more frequently with forms in the browser because forms in InfoPath can authenticate directly with the data source, passing the primary authentication token to this server as the browser does to the server running InfoPath Forms Services.

The Single Sign-On (SSO) feature of Microsoft Office SharePoint Server 2007 is the preferred method of resolving delegation problems in multi-tier architectures, but there are other options if SSO is not available.

MultiTier Delegation Solutions Other Than SSO

Basic/Digest Authentication: This type of authentication is typically used for standard HTML forms, and can be useful for InfoPath forms used in extranet scenarios. A user is presented with a dialog for entering their credentials for access to resources on the third tier Web server, which can be used for one more hop to another Windows computer. If configured for Basic Authentication, the server will send these credentials in clear text, whereas Digest Authentication sends credentials across the network as an MD5 hash or message digest.

Embedded Credentials: Embedding credentials in a Universal Data Connection (UDC) file is possible but should only be used if the security of the username and password for access to the resource is not at risk.

Using an Anonymous/Service Account: If the SharePoint site is configured to allow anonymous access, the server will use an anonymous account to access resources on a third tier.

Kerberos: Kerberos is an authentication protocol designed to support delegation in multi-tier architectures. Using Kerberos, a user authenticates with her username and password to a Key Distribution Center (KDC) server and is issued a Kerberos ticket. The ticket is encrypted and accompanied by a verifier that can only be decrypted by the server. At each tier of the application, the ticket can be independently verified by the KDC without requiring the user’s credentials.

Constrained Delegation: Windows Server 2003 includes two extensions to the Kerberos service called Constrained Delegation (CD) and Protocol Transition. These services allow Windows to obtain a Kerberos ticket on behalf of a user in extranet scenarios where the client cannot use Kerberos or port 88 (the Kerberos port) is blocked. Most Internet servers and corporate firewalls block port 88 by default. CD requires all clients to be Windows XP or later, and all servers to be Windows Server 2003 or later. Additionally, CD must be enabled and configured in Active Directory.

Forms-based Authentication: SharePoint administrators can specify forms-based authentication as the mechanism users use to authenticate to the server. In forms-based authentication, the following occurs:

1. The user makes an HTTP request to the Web front-end (WFE).

2. The WFE returns an HTTP 302 (redirect) response which points to a Web form.

3. The user types credentials into the Web form.

4. The credentials are verified by a third-party plug-in authentication provider and are mapped to credentials that the WFE recognizes (like a SharePoint ID).

At the end of the process, the user has a valid SharePoint ID. However, InfoPath Forms Services does not have a valid Windows credential to use to make a connection, and the form has to use SSO or some other method to get credentials to connect to the data source.

Recommended Authentication Methods: SSO and the Web Service Proxy

SSO: Office Single Sign-on is a different method from the methods listed above for providing alternate credentials for making connections to resources on servers beyond the second tier. SSO is a database that maps applications and user credentials to other credentials, and an API that abstracts the SSO functionality so that any SSO provider which includes a provider for this API can be used. The following SSO providers are candidates for use by a form server administrator:

• Enterprise SSO

• Office Server SSO

• Third-party SSO providers that implement the Office pluggable SSO API

Office Server SSO and Enterprise SSO are based on the same codebase but have evolved independently. Enterprise SSO is included with BizTalk Server 2006. Office Server SSO supports a subset of authentication types that Enterprise SSO supports, but configuration is typically easier and Office SSO is included with Office SharePoint Server 2007.

For more information about configuring Office Server SSO, see Single Sign-on Overview in the Office Server SDK.

Multi-tier Web service Authentication using the Proxy: To enable Web service requests across a multi-tier architecture, the InfoPath Forms Services proxy is provided to forward Web service SOAP messages from the browser form.

The option to enable the proxy is located on the Application Management page of the SharePoint Central Administration site. Click the Manage the Web service proxy link in the InfoPath Forms Services section to enable the proxy for administrator-deployed forms and/or user-deployed forms.

SharePoint Alternate Access Mapping and Data Connections

Alternate Access Mapping in SharePoint provides a mechanism for server farm administrators to identify the different ways in which users can access portal sites, ensuring that URLs are displayed appropriately for the manner in which users access SharePoint sites. For example, a user on a corporate intranet accesses the benefits site for their company using the URL, http://benefits, whereas a company employee browsing from home accesses the same site from the extranet using the URL, https://benefits.mycompany.com.

Alternate Access Mapping does not typically affect how data connections are handled by InfoPath Forms Services. However, if users will be accessing forms from both intranet and extranet locations, the authentication model for data connections should be configured and tested from both locations to ensure proper operation. Connections to a server using a fully-qualified URL, versus a local server name, depend on Alternate Access Mapping to ensure connectivity.

To view Alternate Access Mapping settings in SharePoint Central Administration, browse to the Operations page and click the Alternate access mappings link in the Global Configuration section. For more information about Alternate Access Mapping, search for "alternate access mapping" on the Microsoft Office SharePoint Server TechCenter.

See Also

Concepts

How to: Create and Use a Data Connection Library

Other Resources

Plan alternate access mappings