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
SUMMARYWhen 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.
INTRODUCTIONThis 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 INFORMATIONProblem with Microsoft Security Bulletin MS04-004Microsoft 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 implementationThe following steps illustrate the implementation of an SSO solution by using Basic
authentication. Note This scenario works before you install Security Update MS04-004. - 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. - 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. - 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 sequenceThe 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
- 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
- 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
- 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
- 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. WORKAROUNDUse 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: Download 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 objectUse 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 executionUse 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 ServerXMLHTTPUse 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 applicationUse 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: Download 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: 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: | Major | Last 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 |
---|
|