About Data Connections, Authentication, and Alternate Access Mapping
Applies to: SharePoint Server 2010
In this article
Universal Data Connections
Data Connection Authentication
SharePoint Alternate Access Mapping and Data Connections
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 the Secure Store Service (the replacement for the Single Sign On feature of Office SharePoint Server 2007) to handle authentication issues in multi-tier architectures, and by using the Web service proxy available with InfoPath Forms Services.
Universal Data Connections
SharePoint Foundation 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 InfoPath 2010 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.
Important
Both UDC files need to have the same name. The data connection on the local site can be deleted after a link to the centrally-managed data connection is established, but further form template design using the deleted data connection will not be possible using the Data Connection Wizard.
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)
Note
The Data Connection Wizard for creating a UDC file for an HTTP post is accessed through the Submit Options dialog by clicking Submit Options on the Data tab, not the Data Connections dialog box which accessed by clicking Data Connections on the Data tab.
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.
Note
Each tier for which authentication is necessary is assumed to be a Windows computer on the network, configured for NTLM authentication.
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 Secure Store Service of Microsoft SharePoint Server 2010 is the preferred method of resolving delegation problems in multi-tier architectures, but there are other options if Secure Store Service is not available.
MultiTier Delegation Solutions Other Than Secure Store Service
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 running at minimum Windows XP, and all servers to be running at minimum Windows Server 2003. 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:
The user makes an HTTP request to the Web front-end (WFE).
The WFE returns an HTTP 302 (redirect) response which points to a Web form.
The user types credentials into the Web form.
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: Secure Store Service and the Web Service Proxy
Secure Store Service: Secure Store Service is a different method from the methods listed above for providing alternate credentials for making connections to resources on servers beyond the second tier. Secure Store Service is a database that maps applications and user credentials to other credentials, and an API that abstracts the Secure Store Service functionality so that any Secure Store provider which includes a provider for this API can be used. The following Secure Store providers are candidates for use by a server administrator working with InfoPath forms:
Office Server Secure Store provider
Third-party Secure Store providers
For more information about configuring the Secure Store Service, see the following topics: How to: Use Secure Store Service to Connect to an External System, How to: Use Credentials from the Secure Store Service to Connect to the External System, Business Connectivity Services security overview (SharePoint Foundation 2010), and Business Connectivity Services security overview (SharePoint Server 2010).
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.
Note
The UseFormsServiceProxy attribute in the UDC file must be set to true in order for the SOAP message to be forwarded by the proxy.
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" at Microsoft SharePoint Server 2010 on TechNet.