Avoid Multiple Proxy/Web Server Authentication Engineering Specification

RFE: 4709788: Avoid Multiple Proxy/Web Server Authentication

Author: Zhengyu Gu
Date: 8/14/2002


1 Project Description

1.1 Overview

The goal of this RFE is to resolve multiple Proxy/Web Server authentication while running Java Applet.

Since Java Plug-in 1.4.0, Plug-in no longer relys on browser to provide networking capability, and implements all networking function by utilizing Java networking classes. The benefit of this approach is to eliminate browser depend code, have one code base to with all browsers. As a drawback of the approach, if the browser needs to go through a password protected proxy server, or run an applet on password protected web server, double authentication will result.

When browser try to load a HTML page that contains Applet through a password protected proxy server, or the HTML page is located on a password protected web server, browser will be challenged to authenticate against the proxy server or web server. Once the browser finished loading and start Java plug-in, plug-in will have to open its own connection through the proxy, or to the web server to fetch applet classes. Since the plugin has no knowledge of the result of browser's authentication result, it will be challenged to re-authenticate aginst the proxy server or web server again.

This is annoying side effect, since customers do not understand why they need to authenticate multiple time. The REF is filed to eliminate the second authentication from plugin side.

1.2 Project Dependencies

Netscape 7 and Mozilla implementation depends on Netscape's upcoming API.

1.3 OS and Browser Compatibility and Interoperability

The problem exists on all Oss and browsers. But the REF only targets Internet Explorer and Netscape 7 or later.

1.4 Performance and Scalability

NA

1.5 Security

NA

1.6 Internationalization (I18N) / Localization (L10N)

NA

1.7 Packaging

NA

1.8 Usability

The REF will make plugin more friendly.

1.9 Quality

1.9.1 Unit or Functional Tests to be Delivered
1.9.2 Additional Testing Notes

2 Technical Description

2.1 Architecture

Internet Explorer:

Upon the success of chanellege, Internet Explorer will store the username/password along with the server/security realm that authenticate against in to its undocumented registery based storage, called protected store. Windows exposes the COM interfaces that allow applications to access the protected store. We take advantage of those interfaces, to get the username/password that stored in the protected store when plugin need to authenticate against the proxy/web server.

When ever plugin receives authentication request from networking code through PluginAuthenticator class, it asks BrowserService for BrowserAuthenticator. In this case, a WIExplorerBrowserAuthenticator will be returned, then it passes the server, authenication scheme and security realm information to the WIExplorerBrowserAuthenticator. WIExplorerBrowserAuthenticator then calls into native code to retrieve username/password pair by using "server/security realm" as key.

If the username/password pair is found, plugin will use them to re-authenticate against proxy/web server. But it is transparent to user, so user will not see the prompt for authenication. If the username/password pair is not found, the second authenication request dialog will be prompted.

Netscape 7 and later:

It depends on upcoming Netscape APIs.

2.2 Exported Interfaces/API

2.3 Imported Interfaces/API

2.4 User Interface

3 Marketing

3.1 Justification

3.2 Customer Request

3.3 Competitive Analysis

4 Management and Planning

4.1 Scope/Priority

4.2 Target Release

Mantis

4.3 Resources

4.3.1 Development

Zhengyu Gu

4.3.2 Quality Assurance/Testing
4.3.3 Documentation
4.3.4 Technical Support
4.3.4 Special Hardware/Software

4.4 Schedule

Start Date

End Date

Activity

Owner

Status

 07/08/02

 

 

 

 

 

 

 

 

 

Complete

Started

Not Started

Difficulties

Trouble



Appendices (as needed, suggestions below)

A. Background Information

B. Interface Specifications

C. Notes and Additional Details

D. Miscellaneous

E. Tracking

E.1 Final Webrev
E.2 Bugtraq

Bugid

P

S

Subcategory

Type

Engineer

Synopsis

 

 

 

 

 

 

 



Revision History

Date

Version

Author

Description