Fwd: Re: [Auth]Scenario

[Gordon Hanson]

7/11/01 4:23:53 PM, Ron Burk <address@hidden> wrote:

>Hi,
>
>Here's a possible scenario for use in thinking about the design of
>a single-logon system. This is from the browser-user's
>point of view only, and I'm ignoring any technical hurdles --
>just trying to envision what would be ideal.
>
>* I'm using a Windows machine with IE and I have the appropriate
>     dotgnu plug-in installed for single-logon. When I installed the plug-in,
>    I told it the one-and-only password that I have to remember; the plug-in
>    uses that password to encrypt all other information I give it in the 
>future.
>
>* I go to visit a new web site and it has a restricted section that I can
>    join if I give it an email address and a password. I click on the button
>    that says "sign me up". Note that I do not have to click on any special
>    button that says "sign me up using the dotgnu system" -- the web site is
>    able to be coded in such a way that both dotgnu and normal users can
>    be handled transparently.
>

I like this.  I think that this could be done with some creative use of 
<META>tags. or possibly an object tag/javascript 
combo.  in either case it is transparent to the user, and the site designer 
needs only minimal changes.


>* At this point, because I have not previously "logged on" during this
>    browser session, the plug-in pops up a dialog that asks me to enter
>    my one-and-only password. This would not happen again until I either
>    restarted the browser, or a customizable "timeout" had elapsed, or I
>    explicitly took some action that told the plug-in to again require a 
>password.
>    When asking for the password, the GUI also permits me to specify a
>    non-default location for the personal information database. This allows
>    me to bring my own database on a floppy to someone else's machine,
>    and still make use of my personal logon database while browsing.
>
>* I enter my one-and-only password, and the plug-in then proceeds to
>    inspect what it was the web site was asking for (in this case, an email
>    address and password). At this point, the plugin displays a page (or 
>dialog,
>    or some kind of GUI) that shows what it is prepared to return to the web
>    site. If I have not previously supplied any of the fields, it will 
>typically not be able to
>    suggest defaults. The plugin should offer to generate a "good" password
>    for me -- the web site informed it of any restrictions on character set and
>    length.
>
again could be done through <META> tags.

>* I enter an email address (which the plug-in adds to my local encrypted
>   database for future reference) and ask the plug-in to generate a password
>    for me. It generates a long garbage-looking password that would be unlikely
>    to be susceptible to dictionary attacks. I, of course, will never have 
>to remember
>    what that password is. I check the box that says "Logon Automatically", 
>which
>    tells the plug-in I don't need to inspect these logon parameters the 
>next time
>    I log on to this site. Finally, I push the "OK" button, and the plugin 
>transmits
>    the logon information to the web site, which then allows me access to the
>    restricted pages.
>
>* Next week, I go to another web site that is similar in its demands.
>    This time, when the plug-in asks me what information I want to supply,
>     the email address I entered previously is present in a drop-down combo
>     box. I can accept it as-is, or enter another email address.
>
>* Next month, I return to web site #1. Assume that I entered my
>    one-and-only password earlier during that browser session. This time,
>    when I click on the web site's "logon" button, the request for credentials
>    and the response all happen invisibly, and I am delivered right to
>    whatever page normally greets people who have just logged on. Joy!
>
>This doesn't exercise anywhere near all the things to be considered during 
>the design,
>but it's what I personally envisioned as characteristic of the key 
>functionality.
>Is roughly what anyone else envisioned as the basic idea?
>
>
>Ron Burk
>Windows Developer's Journal, www.wdj.com
>
>_______________________________________________
>Auth mailing list
>address@hidden
>http://dotgnu.org/mailman/listinfo/auth
>



This is a great use case for single logon functionality. I just sat down to 
write one like this. guess I don't have to now. :>]

the pieces that I think need to be considered are:
1. how can we tell that a logon button has been pressed so we can kick off the 
lookup-site/send-password function?
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.  
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)
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)
5. should descriptor for the non-default location for the authentication 
database be an URI?

So now we have single logon, and Identity verification, what else can 
autorisation do for us?


Gord Hanson