DB User Intf Proposal
Andrew Adams
Tue May 17 16:10:58 CEST 1994
Hi all.  I've been playing with a couple of ideas and wanted to run them past
you all. 
We are all concerned with having users update and maintain their own 
information in various databases; routing registry dbs, contact dbs, etc.
Along with this desire comes the issue of authentication.  Below are some 
thoughts on using HTML and a WWW browser such as NCSA Mosaic as a user
interface to databases.  The users are probably better off in the long run
if we agree on the same approach and tools.
I've been investigating the possibility of using HTML+ and an HTML browser
such as XMosaic as a front end for our routing registry database.  
For those of you who don't know about World Wide Web stuff, here's a quick
glossary.
    HTML stands for HyperText Markup Language.  HTML is a page description 
    language which allows you to define how pages look; for example, define 
    sections that should be in bold or italics, etc.  In addition, it also 
    allows you to create hypertext links between pages.  
    HTML+ is the follow-on to HTML. A superset of HTML, it also defines 
    (among other things)_input_forms_.  On a unix workstation running XMosaic, 
    these forms appear as Motif scrolled lists, text widgets, push buttons, 
    etc.  Using a well defined application programming interface, data entered 
    into a form can be passed off to any application you write, turned into a 
    database query (or anything else for that matter), and then the results 
    handed back to the user in the form of a new hypertext page.  
    
    HTTP is the HyperText Transfer Protocol, the application level protocol 
    used to serve up HTML(+) docs.  
    
    Httpd is the daemon which serves documents on a given machine.
It's important to understand the HTML(+) & Mosaic are information _browsing_
_tools_ and not database technologies.  The database technology that sits
behind HTML(+)/Mosaic is independant from HTML(+)/Mosaic.
Ok, having said all that, I was thinking that it might be neat to let users 
enter and/or browse registry info using HTML(+) and Mosaic.  For example, a 
user could start up XMosaic and load the "Registry Info Browser" page which 
would prompt them for a name and password. (See paragraphs on authentication 
below).  The name could then be used to determine the ASs for which the user 
is the contact, and a screen displayed which would allow them to view their 
AS's current policy and submit changes if necessary.
To test the feasability of this approach a bit, I cobbled together a little
application to basically do the operation described in the paragraph above.
To run the demo you need to have a Web browser like Mosaic running on your
machine. (Note that MacMosaic won't work 'cause it doesn't yet handle the
'forms' stuff.)  Fire up XMosaic and click "Open..." button at the bottom
of the "Document View" window.  In the pop-up dialog that appears, enter
http://shockwave.merit.edu/ala_htdocs/pass.html
A page with "This is a test" at the top, and 'Name' and 'Password' input
fields should appear.  In the 'Name' field enter 'bmanning'.  In the
'Passwd' field enter 'xyzman'. Then click the 'Submit Query' button.
A new page should appear which begins 'Access Granted to Bill Manning'.  This
page should also have a list widget full of the ASs for which Bill Manning has
authority.  This list is the result of sending off an SQL query to our Informix
AS Contacts database. Select an AS to modify, say AS 114, and then click 
'Submit Query.'
A new page should appear for which the heading reads "Policy for AS114". The
policy for AS 114 appears below the heading in an editable text widget.
The policy is simply the output of a "whois -r rrdb.merit.edu AS114" command.
Here now you could change the policy, click 'Submit Query' and have the changes
made to the database. 
So authentication is definitely an issue here.  I'm still learning about this
stuff but from what I understand so far, a couple of different levels of
authentication are possible.  The authentiation used in my little prototype
above is the simplest and thus, least secure.  The password and user name are
sent, over the net, to an authentication program I wrote.  The name is looked
up in a local password file and the supplied passwd is compared with the 
stored, encrypted password.  This is arguably as secure as telnet.  (Assume
for a second that putting a Web deamon, httpd, on your machine isn't a big
security hole in itself.  I don't know how secure httpd is.)  Actually, it
is arguably slightly more secure than telnet because, if I read the doc
correctly, the passwd string sent from a password widget is uuencoded.  Thus, 
anyone running a sniffer would have to explicity look for and decode this.
For stricter authentication, it appears that the HTTP protocol has constructs
built in which allow for Kerberos, PGP and PEM.  I don't yet know exaclty how
to implement a system using these facilities, having only quickly browsed
the documentation.
Reasons for using WWW, HTML+ and Mosaic for browse and update registry info.
(1) Ease of use .... for some operations.  For occasional users and for 
    operations which don't require a lot of hand editing, a point and click
    interface might be easier to use.  ftp'ing a large file of network numbers
    might still be the easiest way to do, say, network additions.
(2) Software Exists Now on Multiple Platforms
    HTML is an IETF standard (pretty sure about this) and HTML+ is in IETF
    Draft form.  NCSA has Mosaic clients that run on nearly all Unix 
    workstations.  (The Mac client which supports HTML+ forms is rumored to
    be forthcoming, as is a Window's version.)  This means we need not 
    distribute client code to handle the user interface.
Thoughts?
-Andy
-------- Logged at  Tue May 17 17:40:48 MET DST 1994  ---------
[ rr-impl Archive ]