Re: [Auth]Scenario

[Ron Burk]

If it's possible to do it without JavaScript, that would be great.
Otherwise, you have to document that it won't work with browsers
where JavaScript is disabled. In thinking about web sites, I try to
shoot for the least common denominator when possible: no Java,
no JavaScript, no cookies, and the client IP address can change from
one HTTP request to another.

I have never written a plug-in, so if someone else has, maybe
they could summarize what the options are for communication
between a plug-in and a web site. Here's my very limited understanding
(hopefully someone will correct the incorrect parts). I guess I should
first say that I'm thinking of a Netscape-style plug-in that would
be largely code-compatible with both IE and Netscape -- maybe other
people are envisioning writing a lot of independent code for
each individual browser, not necessarily using the standard Netscape
plug-in API at all.

AFAIK, a plug-in is associated with a MIME type, and it only
gets a chance to "get control" when the browser encounters
a page containing an <embed> tag that refers to that MIME type,
or when a page itself comes back declared as being of that MIME type.
AFAIK, the browser does not let the server know which plug-ins
are installed (or at least, I just did a dump of an IE 5.01 request,
and I see that it just says "Accept: */*", which doesn't seem to
give me a clue about what it really accepts :-).
Once it gets control, the plug-in can have its own window,
can make "behind the scenes" requests (POST/GET) to the server and
read back responses. Are there other details about the
Netscape plug-in API that are relevant to this problem?

I'm really exceeding my actual knowledge now, but I have
this vague memory that my server can transmit a multi-part
MIME in response to a GET. If so, I wonder what the standard
browsers would do if I sent a two-part, the first being a MIME
type that they don't understand (dotgnu MIME type) and the
second being my fallback text/HTML for people who aren't using
dotgnu. If they would just ignore the first part when it's a MIME
type they don't know, that might be an easy way for servers to
transparently degrade to the dotgnu case. Come to think of it,
it's something I might enjoy, but probably not that easy for people
who don't like to whack on Apache, and definitely a pain for
some non-Apache servers. Probably a bad idea (but included
here so I can remember why it's a bad idea :-).

Maybe <noembed> would do the trick.

Random thought: I wonder if IE supports the "pluginspage" attribute
of the <embed> tag.

> 1. how can we tell that a logon button has been pressed so we can kick off 
> the lookup-site/send-password function?

If pressing the logon button takes you to a web page that
refers to the plug-in's MIME type, then the plug-in should
get the chance to do its thing.

> 2. how can we tell what information is being asked for? I can see how this 
> would work by embedding either an object
> tag, or a set of meta tags in the page, and then using the document object 
> model to retrieve that info.

Seems like, for example, the web server could supply a page
that contains an <embed> tag whose src attribute refers to
a something.dotgnu file back on the server. That file can have
the information request in any form you care for; XML is always
buzz-word worthy, of course :-). The plug-in would be loaded,
get a chance to read the server's request (possibly in the
form of XML), and have a designated space on the page
to display its UI.

> 3. I can see that it would be desireable to temporarily cache the pass 
> phrase, but I would be more comfortable if we
> could guarantee that it is never stored on the hard drive (eg. the virtual 
> memory subsystem should not EVER write it to
> disk)

I don't know about caching, per se, but it's going to exist unencrypted
in memory for at least a brief period, or at least I know of no way round it.
Presumably you're saying never stored *unencrypted*. If the attacker
has access to your CPU, I'm not sure there's any way to prevent
a password theft, and it seems like the attacker would have simpler
opportunities than trying to snag it from the swap file. It's a security
thought worth considering, though, for sure.

> 4. Are we going to use HTTP as the transport protocol ? Are we going to 
> use XML-RPC, SOAP or IIOP as the
> communication protocol? (My vote goes for SOAP as it is being ratified by 
> the w3c)

My vote would be for focusing on making it dead easy for as many
web site designers as possible. If you can do that with SOAP, then
great. I'm not sure how that fits with using a standard plug-in.
Despite the fact that the browser is technically the client, the interaction
we're interested in is really a conversation driven by the web server,
I'm thinking. Maybe it's possible to view it either way, though.

If the system were implemented with a Netscape-style plug-in,
which the web site could communicate with merely by placing
<embed> tags in their HTML (which in turn might cause the
plug-in to reply via whatever kind of POST or GET the web server
cares to specify), that might be the simplest form of communication.
You could use <meta> tags to supply info, but for some reason
it feels cleaner to me (with my webmaster hat on) to be able to
place the information request in a separate URL with its own
file format that gets fetched transparently (e.g., via an <embed>
reference or somesuch).

> 5. should descriptor for the non-default location for the authentication 
> database be an URI?

Excellent -- I never thought of that. If I chose to store my personal 
encrypted database
on my own web server, I could then use it from any machine on the web 
(preferably
via https, of course). No floppy for me!

Ron Burk
Windows Developer's Journal, www.wdj.com