Advanced server-side authentication for data connections, part 1
To tier three... and beyond!
Real-world enterprise applications are seldom restricted to a single server. Anyone who has created a nontrivial multi-tier application in a Windows environment has had to work around a fundamental limitation in NTLM authentication: namely, that NTLM authentication tokens cannot be delegated past the second tier.
Could you bounce off the wall and say that again?
OK, in simpler terms:
When you log onto your workstation, you present windows with primary evidence of your identity in the form of a username and a secret – usually a password, but sometimes a certificate or a biometric identifier such as a fingerprint.
When you connect to a web application in a browser, your workstation contacts the web server and tells the server who you are. The server trusts the workstation because it knows that the workstation has primary evidence of your identity, but the server has only second-hand evidence.
When the web server connects to the data server, it passes your authentication token, but the data server won't accept it because the chain of trust is too long. The data server has only third-hand evidence of your identity. Bzzzzzzzzzt – thank you for playing!
With InfoPath 2003, you never had to worry about these issues when designing your form. You ran InfoPath on tier 1, and the database, Web service, or SharePoint site on tier 2 trusted your computer's first-hand evidence. Now that you are designing forms that run in a web browser, you'll need to think about tier 3.
There are a number of ways of dealing with tier 3 and beyond in forms services. I'll start by briefly describing three simple techniques for noncritical applications, then I'll move on to enterprise-quality solutions, culminating in two technologies that are specific to Microsoft Office SharePoint Server.
Keep in mind that for form templates that are not admin-approved and fully trusted, the connection settings need to be stored in a Universal Data Connection (UDC) file in a Data Connection Library in order to make a connection to another domain.
Anonymous connections
For trivial data connections, such as looking up a list of states to populate a drop-down list, you can simply allow anonymous users to access your data. Removing the need to authorize the user means that it's no longer a problem that your identity can't be verified on tier 3.
HTTP Basic Authentication
In Basic authentication (or digest, which is a slightly more secure version of the same protocol), your browser prompts you to enter your username and a password, which are then passed in cleartext (or in digest form) to the web server. The web server now has primary evidence of your identity, so the data server can trust it to tell it who you are. You can set up IIS on your SharePoint server to use Basic authentication instead of Windows Integrated authentication. While this is a quick way to do an end run around the tier 3 problem, it presents an awkward user experience on the intranet. This is better suited to the extranet, where getting prompted for additional credentials is a more familiar experience. Don't forget to set up SSL so that your users' credentials are encrypted on the wire. Otherwise, anybody monitoring your server traffic can read the passwords as they pass by.
Embedded SQL credentials
It's common practice in web applications to connect to a database using a SQL username and password embedded in the connection string. Since this requires putting a password in cleartext in a configuration file, it is not considered a secure method of authentication. By default, user form templates on the server are not allowed to use embedded SQL credentials.
Kerberos
Unlike NTLM authentication, a Kerberos authentication token, called a "ticket", can be independently verified at any point in an n-tier system and thus can be delegated indefinitely within the window of time that the ticket is valid. For enterprises where Windows XP or better is the standard desktop and Windows Server 2003 is the standard server, Kerberos can replace NTLM as the standard authentication method in Active Directory. This is the preferred method of overcoming the 2-tier restriction on token delegation when available.
Constrained Delegation
In constrained delegation, two services on two servers can be configured to allow a specific set of user accounts to be delegated from one service to the other without requiring independent verification of a password. While this is considered a secure option, it is notoriously difficult to set up and maintain.
Office Single Sign-on
Office Single Sign-on (SSO) is a service on Microsoft Office SharePoint Server which was created to help applications on the server overcome authentication delegation issues. At its heart, SSO is simply a database which stores encrypted username and password pairs. An application running on the server can obtain a username and password associated with a known SSO application definition and can then use those credentials to log on to Windows and make a trusted connection to a data source. A form running on the server can use SSO to connect to external data by specifying an SSO application ID in the UDC file containing the connection settings.
Web service proxy
InfoPath Forms Services includes functionality to forward Web service requests from a form. The web service request is made using the identity associated with the SharePoint web application. In order to allow the web service to authorize access to the external data, the user's Windows username is passed in the SOAP header using a WS-
Security UsernameToken
In my next two installments, I'll describe in more detail how to use Office Single Sign-on and the Web service proxy to connect to enterprise data from your browser-enabled forms.
In my next post we'll cover Single Sign On and write some code.
- Nick
Program Manager
Comments
Anonymous
June 27, 2006
In the first part of this series I introduced the concepts involved in three tier authentication....Anonymous
July 03, 2006
This is the final segment of my three part series. In the first part of this series I introduced the...Anonymous
February 19, 2007
Recently lots of Microsoft partners and customers are interest in the Form Server/Form Services in MOSSAnonymous
May 08, 2007
If I load the form in the InfoPath Desktop Client, the form submits just fine. However, if i load via the web browser i get a "An error occurred while the form was being submitted." how do i get more info on this error?
It's working properly If the form is opened in infopath environment. But it's giving error while I am opening it as browser enabled. Here I am giving the steps I have taken: I created a web service which accepts input as parametres. then create a new infopath form to submit the data from textboxes present in the form through submit button powered by the above said webservice. It's working properly If the form is opened in infopath environment. But it's giving error while I am opening it as browser enabled. I am also unable to display data while the form is opened with browser enabled. the following error is showing. There has been an error while processing the form. Click Continue to resume filling out the form. You may want to check your form data for errors. Click Start Over to load a new copy of the form. An error occurred accessing a data source. An entry has been added to the Windows event log of the server. Log ID:6932
Anonymous
May 22, 2007
The comment has been removedAnonymous
May 23, 2007
If you've gone through all of the stuff in the "making data connections work on the server" article thread, and you still are having trouble, you might want to fiddle with either the data size threshold or the server timeout threshold. Chances are either your web service is returning more data than the server admin allows, or you're taking too much time. The defaults are pretty aggressively low. Setting your server's trace level to verbose and then reading the logs that result may give you actionable information.Anonymous
August 19, 2008
Hi, It's been a while since I posted. As you may imagine, July wasn't the most popular monthAnonymous
August 28, 2012
If I build an InfoPath 2010 form with a People Picker compatible with InfoPath Filler Form 2007, why doesn't the People Picker resolve for my InfoPath 2007 users?