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.