ietf-openproxy
[Top] [All Lists]

web reverse proxy to provide intranet access from web enabled phones and other small gadgets

2000-12-11 13:24:40
Hi.

I'm not so sure this is 100% compatible with this BOF's charter, but it 
seems to be really related/close.  Anyway, I think this can eventually 
be a Best Current Practices or Informational kind of RFC.

What do you guys think?  I'm currently at the IETF site, I'd happy to 
have a verbal conversation on this topic.  So if there is someone who 
is willing to have a talk in person, please let me know.  Needless to 
say, discussions, suggestions, etc. via email are also welcome.


*** Introduction ***

As of now, there are more than 20 million Internet connected cell 
phones in Japan.  Web enabled cell phone will become common eventually 
all over the world, I suppose.  Then the scheme explained here might be 
used widely.

Let's assume you have a WAP phone with Internet connectivity.  Our 
scheme is to provide intranet web access to your WAP phone with the 
same security level as dial up to your office with one time password.  
We don't require any changes to WAP handset, WAP gateway, or intranet 
web server.  This scheme is actually not only for WAP but also for any 
Internet connected gadget as long as it speaks HTTP from server's point 
of view.  But to make the discussion as concrete as possible, I assume WAP here.

The purpose of this presentation is to share our insight with the 
Internet community and raise issues.  If this kind of scheme become 
common, the scheme itself and/or requirements for handsets and web 
access service are better to be standardized.


*** The Basics ***

The basic idea is to use web reverse proxy with a certain set of 
functionalities.  The format of URL's to access intranet would be:

https://<revproxyhostname>/revproxy/<userid>:<session ID>/
        <protocol>/<intranetwebserver>[:<port>]/<path>

We use SSL to access the reverse proxy to secure the connection between 
handset and the reverse proxy.

Let's assume you have an intranet WML page for corporate directory whose URL is

http://corpdir/compact.wml

Then, your WAP phone would have a bookmark to

https://waprevproxy.foo.com/revproxy/johndoe:/http/corpdir/compact.wml

assuming your reverse proxy is named waprevproxy.foo.com and your user 
ID is johndoe.

When you select the bookmark to refer to the corporate directory, the 
reverse proxy would display a form asking for password.  And the form 
has the intranet URL you want to go to (http://corpdir/compact.wml) and 
your ID (johndoe) in hidden fields or in action URL.  The form would be 
posted and the reverse proxy checks if the password entered is correct 
or not.  If the password is correct, then the reverse proxy assigns a 
randomly generated session ID and returns HTTP redirect to:

http://waprevproxy.foo.com/revproxy/johndoe:12fab9f82cc7bcaa/
       http/corpdir/compact.wml

Then handset's browser requests

GET /revproxy/johndoe:12fab9f82cc7bcaa/http/corpdir/compact.wml

to waprevproxy.foo.com.  This time, the reverse proxy recognizes a 
valid session ID in the URL, and sends an HTTP request for 
http://corpdir/compact.wml.  Then the reverse proxy relay the response 
from the "corpdir" web server to the WAP handset.


*** Design Rationale ***

As you can see, we don't use the Authorization: HTTP header for 
authentication.  The reason is that if we did, users would have to 
enter both user ID and password, which seems to be much more 
inconvenient than entering only password.  Because character entry from 
phone keypad is really pain in the ass especially if you have to enter 
a long string.

You might wonder why user and session identifications are embedded in 
URL rather than using cookie.  This is because cookie is not always 
supported by Internet connected gadgets.  Some WAP gateways support it, 
but others don't.


*** URL Rewriting ***

HTML contents of intranet web servers would contain URL for hyper 
links, embedded images, etc.  If such URLs are in the

/absolute/path

or

http://another_intranet_web_server/path/on/the/server 

format, then such URL's are not recognized as expected on the WAP 
handset accessing intranet via the reverse proxy.  So the reverse proxy 
is better to rewrite those URL's so that they are recognized as 
expected.  If all URL's in intranet web contents are relative path, 
then there is no need for URL rewriting, but that's not true in most cases.

The exact detail of URL rewriting should be specified so that contents 
creators can make their contents reverse proxy safe.


*** Authentication Propagation ***

The reverse proxy is required to have a means to provide user 
identification to intranet web servers so that users don't have to 
enter his identification from handset.  An easy way is to provide such 
identification as a cookie like REVPROXY_USER=username but it's not 
secure since intranet web servers blindly trust the reverse proxy.  A 
better way is to get a credential from authentication mechanism.

Let's say you are using a single sign-on mechanism in your internal 
network.  Then the web reverse proxy would use a single sign-on 
participating web server for the user authentication of its users.

                           HTTP req including
                           user ID & passwd in
                           the basic auth header      
internal web server      <--------------------  the web reverse
protected by the single  -------------------->  proxy
sign-on mechanism          HTTP res including
                           the auth token

Once the reverse proxy gets a authorization token for a user, then, the 
rev proxy can provide the token to internal web servers to access 
protected contents without asking ID and password to the user.


*** Status of Implementation ***

We have an alpha version of implementation written as Java Servlet.  
It's currently basically for i-mode cell phone in Japan whose mark up 
language is a subset of HTML.  But we plan to adopt the program to WAP 
within 6 months.


Regards,
Hideyo Imazu. 


<Prev in Thread] Current Thread [Next in Thread>