Implement a Single-Sign On solution by using basic authentication and Internet Explorer client (837104)



The information in this article applies to:

  • Microsoft Internet Explorer (Programming) 6.0
  • Microsoft Internet Explorer (Programming) 5.5
  • Microsoft Internet Explorer (Programming) 5.01

SUMMARY

When you install the Security Update in Microsoft Security Bulletin MS04-004 on your computer, some of your Web applications that pass credentials through a URL may break. This article discusses several methods to work around this problem and discusses the limitations of each method.

INTRODUCTION

This article discusses how to pass the user credentials through the URL for Single Sign-On (SSO) by using Basic authentication. When you install the Security Update in Microsoft Security Bulletin MS04-004, you cannot pass credentials through the URL.

MORE INFORMATION

Problem with Microsoft Security Bulletin MS04-004

Microsoft Security Bulletin MS04-004 provides a security update for Microsoft Internet Explorer and for a dependency component that is named WinInet. Security Update MS04-004 complies with section 3.2.2 of Request for Comments (RFC) 2616 and section 3.3 of RFC 1738. Both sections of these RFCs state that HTTP URLs must have only the following format:

http://host:port/path?querystring

Note host, port, and path are placeholders for the host name, the port number, and the location of the requested Web page on the server, respectively. querystring is a placeholder for the parameters of the query string that must be passed to the server.

Security Bulletin MS04-004 includes an update that prevents a particular URL spoofing issue. Spoofing is the practice of tricking users into providing passwords and other information to allow unauthorized access into a system. In this scenario, users are tricked into thinking that they are browsing a particular Web site, when they are actually browsing a different Web site. Security update MS04-004 prevents the URL spoofing issue. However, after you apply Security Update MS04-004, some Web applications may break. The Web applications that are affected rely on the feature that passes credentials through the URL

Note Because Basic authentication credentials are passed across the network in clear text for every request that is sent from the Web client to the Web server, limit the use of Basic authentication. Only use Basic authentication when no other authentication methods are available. Also, use Basic authentication in conjunction with encryption such as TLS/SSL.

Microsoft concurs with the following warning that is provided in section 7 of RFC 2396:

It is clearly unwise to use a URL that contains a password which is intended to be secret. In particular, the use of a password within the 'userinfo' component of a URL is strongly disrecommended except in those rare cases where the 'password' parameter is intended to be public.

Microsoft recommends that you do not implement Basic authentication-based SSO solutions. However, this article contains several methods that you can use to work around the behavior that occurs after you apply Security Update MS04-004. When you use this method, previous systems that implement Basic authentication-based SSO solutions work just like they did before you installed Security Update MS04-004.

For additional information about Microsoft Security Bulletin MS04-004, visit the following Microsoft Web site:

SSO implementation

The following steps illustrate the implementation of an SSO solution by using Basic authentication.

Note This scenario works before you install Security Update MS04-004.
  1. A Web client requests PageOfInterest.asp from ServerA.

    Note PageOfInterest.asp, and ServerA are placeholders for the name of the requested page, and the name of the server where the requested page is stored, respectively.
  2. ServerA responds to the Web client with a message the instructs the Web client to retrieve PageOfInterest.asp from the following location:

    http://sbUsername:sbPassword@ServerB/SomePath/PageOfInterest.asp

    This instruction is either sent in the Location header of an HTTP response with status code = 302, or it is sent as a "meta refresh" tag in the message body of an HTTP response with status code = 200.

    Note sbUsername, sbPassword, ServerB, and SomePath are the placeholders for the username, the password, the name of the server where the requested page is stored, and location of the requested Web page on the server, respectively. Modify these values according to your environment.
  3. The Web client requests PageOfInterest.asp from ServerB, and then provides credentials when challenged.
When Internet Explorer canonicalized a URL before you installed Security Update MS04-004, WinInet saved any credentials that you encountered between the protocol and host sections of the URL for later use in the communication between the Web client and the Web server. WinInet is the component that Internet Explorer uses to communicate over TCP/IP. If a subsequent request to the same Basic authentication realm returned a WWW-Authenticate: Basic response header, WinInet used a correctly formatted Authorization: Basic request header to issue another request to the Web server that includes the credentials that were saved during canonicalization. When the credentials are saved, the Web client can authenticate to the Web server, and the user is not prompted for credentials.

Sample sequence

The following is a sample of the HTTP data that is exchanged between an Internet Explorer client and a server computer that is running Microsoft Internet Information Services (IIS) in a typical Basic authentication sequence.

Note This sample was collected by using the WFetch utility. The \r\n characters represent the hexadecimal characters 0D 0A, or the ASCII character CRLF. For additional information about the WFetch utility, click the following article number to view the article in the Microsoft Knowledge Base:

284285 How to use Wfetch.exe to troubleshoot HTTP connections

  1. The browser issues an anonymous request to the Web server.
    GET /SomePath/PageOfInterest.aspx HTTP/1.1\r\n
    Host: ServerB\r\n
    Accept: */*\r\n
    \r\n
    
  2. The Web server replies to the Web client that access is denied, and that the requested resource requires Basic authentication credentials.
    HTTP/1.1 401 Access Denied\r\n
    Content-Length: 4431\r\n
    Content-Type: text/html\r\n
    Server: Microsoft-IIS/6.0\r\n
    WWW-Authenticate: Basic realm="ServerB"\r\n
    X-Powered-By: ASP.NET\r\n
    Date: Mon, 16 Feb 2004 00:38:11 GMT\r\n
    \r\n
     [ *** HTTP MESSAGE-BODY REMOVED FOR BREVITY *** ]
    \r\n
    
  3. The browser re-issues the same request that it sent in step 1. However, this time the browser inserts the Authorization: Basic header that includes the user's credentials.
    GET /SomePath/PageOfInterest.aspx HTTP/1.1\r\n
    Host: ServerB\r\n
    Accept: */*\r\n
    Authorization: Basic TG9jYWxVc2VyOkxvY2FsUGFzc3dvcmQ=\r\n
    \r\n
    
  4. The credentials are valid and the user has permission to access to the requested resource. Therefore, the data that is requested is returned to the user.
    HTTP/1.1 200 OK\r\n
    Date: Mon, 16 Feb 2004 00:40:37 GMT\r\n\
    Server: Microsoft-IIS/6.0\r\n
    X-Powered-By: ASP.NET\r\n
    X-AspNet-Version: 1.1.4322\r\n
    Set-Cookie: ASP.NET_SessionId=zzseaci1a4tyhrymokckmau2; path=/\r\n
    Cache-control: private\r\n
    Content-Type: text/html\r\n
    Content-Length: 44\r\n
    \r\n
    [ *** HTTP MESSAGE-BODY REMOVED FOR BREVITY *** ]
    \r\n
    
The significance of this communication sample is to demonstrate that in a typical Basic authentication sequence, the Web client will first try to communicate by using anonymous authentication (that is, no Authorization: Basic request header is sent). The server then replies with a response that contains a 401- Access Denied status code and a WWW-Authenticate: Basic response header. Typically, between steps 2 and 3, the browser prompts the user with a dialog box that prompts the user to enter credentials in response to the server's Authenticate: Basic challenge. However, per RFC 2617, most browsers (including Internet Explorer) provide the Authorization: Basic header if the user has already provided the Basic authentication credentials for the specified realm. After you install Security Update MS04-004, Internet Explorer discards the credentials that are passed through the URL, and WinInet no longer has the credentials to forward automatically. Therefore, the user receives a dialog box that prompts the user for Basic authentication credentials.

WORKAROUND

Use one of the following methods to work around this problem. The proposed approach in this section refers to three hosts: ServerA, ServerB, and the Web client. Where ServerA is the name of the requested page, and ServerB is the name of the server where the requested page is stored.

Note Because the changes that are made in Security Update MS04-004 apply only to Microsoft Windows versions of Internet Explorer, the Web client is assumed to be a version of Internet Explorer that has been updated with Security Update MS04-004.

You can download code samples of the various workarounds that are suggested in this article. The following file is available for download from the Microsoft Download Center:
DownloadDownload the Code Samples package now. For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base:

119591 How to Obtain Microsoft Support Files from Online Services

Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help to prevent any unauthorized changes to the file.

Method 1: Use the XMLHTTP object

Use the XMLHTTP object to make an intermediate request in client-side script that is running on the Web client, instead of relying on Internet Explorer to automatically redirect when it receives the 302 (redirect) response from ServerA. The XMLHTTP object exposes several properties that allow developers to collect data from the HTTP Response headers, the QueryString, or the Message-body of the HTML document.

Requirements
  • (MSXML) must be available for scripting on the client (MSXML 3.0 is included with Microsoft Windows 2000 and later, and is included with Internet Explorer 6.0 and later).
  • ServerA must support modification to its configuration. This modification permits ServerA to send the Web client to a page that loads the XMLHTTP object. The XMLHTTP object intercepts the redirect message instead of trying to process the redirect message as it before you installed Security Update MS04 004.
Limitations
  • A bug in MSXML prevents this solution from working without additional configuration. This bug has been fixed. However, Internet Explorer clients that have installed the Security Update MS04-004 require an updated version of msxml?.dll. For additional information about the updated version of msxml?.dll, click the following article number to view the article in the Microsoft Knowledge Base:

    832414 XMLHTTP call fails for URLs with embedded user credentials

Method 2: Use a server-side application that can modify the HTTP data stream before script execution

Use a server-side application that can modify the HTTP data stream before script execution (such as an ISAPI filter or a .NET HttpModule) on ServerB to intercept the credentials that are transmitted by the Web client through another section of a valid HTTP request, and then generate a valid Authorization: Basic header to pass down to the Web server for authentication.

Requirements
  • ServerA must support modification to its configuration (to send the Web client the credentials in another section of the response, such as the QueryString or in a Cookie. Therefore, the Web client can transmit those credentials to ServerB for the ISAPI filter or HttpModule to intercept)
Limitations
  • ServerB must support the server-side application, such as ISAPI filters or .NET HttpModules, that is used in this workaround.

Method 3: Use a server-side component such as WinHttp or ServerXMLHTTP

Use a server-side component such as the WinHttp object or the ServerXMLHTTP object inside an ASP page or an ASPX page on ServerA to retrieve the content from ServerB directly, (that is, on behalf of the user), and then return that content to the Web client. In this scenario, the Web client never communicates with ServerB.

Requirements
  • The WinHttp.WinHttpRequest.5.1 Prog ID must be available on ServerA. By default, WinHttp.WinHttpRequest.5.1 is included with Microsoft Windows 2000 SP3, Microsoft Windows XP SP1, and Microsoft Windows Server 2003.
Limitations
  • WinHttp.WinHttpRequest.5.1 expects ServerB to return completed content to the Web client. In this scenario, the Web client has the version of Internet Explorer installed that has been updated with Security Update MS04-004. If this Web client expects to conduct synchronous communications with ServerB (through an ActiveX control or a Java applet), this solution may not work.
  • Microsoft does not recommend this workaround because the performance of ServerA will affect the functionality of the Web client if the Web client has the version of Internet Explorer installed that has been updated with Security Update MS04-004.

Method 4: Use a custom client-side application

Use a custom client-side application such as an ActiveX control that calls the WinInet API or the WinHttp API, or a .NET Windows Form control that uses the System.Net.Sockets namespace, that you can create an instance of in client-side code in the browser. This custom object must be able to establish a TCP connection, and must be able to transmit well-formed HTTP(S) messages (including generating an Authorization: Basic request header).

Requirements
  • ActiveX solution: Users must have permission to install ActiveX controls on their computer.
  • ActiveX solution: Security settings in Internet Explorer must allow execution of ActiveX applications.
  • .NET WinForms solution: The Microsoft .NET Framework must be installed on the Web client.
Limitations
  • Users in managed environments may not be able to modify their download and execution settings to allow ActiveX controls or .NET WinForms controls.
  • WinHttp (called directly through COM, or through the .NET Framework) uses a different set of APIs than WinInet (that is used by Internet Explorer). Therefore, any authentication in a client-side application must occur for each request that is sent to the Web server.
  • .NET WinForms solution: Before executing the client-side control, you must configure the .NET Security feature on each Web client.
  • .NET WinForms solution: The only way to remotely verify that the .NET Framework is installed on an unmanaged Web client is to query the HTTP User Agent string that is provided by Internet Explorer. However, because this value can be changed with a registry setting, do not consider this kind of detection authoritative.

REFERENCES

The following file is available for download from the Microsoft Download Center:
DownloadDownload the Samples.exe package now. For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base:

119591 How to Obtain Microsoft Support Files from Online Services

Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help to prevent any unauthorized changes to the file. For more information, visit the following Microsoft Developer Network (MSDN) Web sites:

DHTML and .NET Host Secure, lightweight client-side controls in Microsoft Internet Explorer
http://msdn.microsoft.com/msdnmag/issues/02/01/userctrl/

For additional information about Request for Comments (RFC), visit the following RFC Web sites: For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

815148 How to adjust .NET Framework security on a zone-by-zone basis

259100 SAMPLE: Vbhttp.exe demonstrates how to use HTTP WinInet APIs in Visual Basic

303436 SAMPLE: Visual C# .NET networking classes HTTP Internet client

182569 Description of Internet Explorer security zones registry entries

834489 A security update is available that modifies the default behavior of Internet Explorer for handling user information in HTTP and in HTTPS URLs

284285 How to use Wfetch.exe to troubleshoot HTTP connections

836640 You cannot access Outlook Web Access and single sign-on Web applications by using XMLHTTP after you apply Internet Explorer Security Update MS04-004


Modification Type:MajorLast Reviewed:4/21/2006
Keywords:kbXML kbWebServer kbWebBrowser kbServer kbnetwork kbhttp kbDLL kbClient kbActiveXScript kbweb kbUser kbSecurity kbQuery kbPerformance kbheaders kbformat kbfilters kbDownload kbbrowsing kbAuthentication kbinfo KB837104 kbAudDeveloper