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