Date: Mon, 20 Mar 1995 16:09:18 -0500
>Reply-To: [log in to unmask]
>Sender: HP-3000 Systems Discussion <[log in to unmask]>
>From: Kyle Parrish <[log in to unmask]>
>Could people begin enlightening me as to how I can use netscape to
>submit login names and passwords to the 3000, and then submit queries
>to Image/SQL?
Kyle,
STOP! thinking Telnet or logon session. HperText Transfer Protocol HTTP is
nothing like it! I'll answer the logon question in the authentication section.
First, Netscape protocol uses something called "stateless" design. This
means all transactions are immediate, i.e.,
* Connect
* Request
* Response
* Close
Once a connection establishes itself between client and host (server), the
client sends a request to the host while invoking the proper protocol method
(native http or others) specified within the URL. The host responds to the
client's request and the connection to the host server terminates. The Web
browser processes the contents of the server's response according to the
service protocol rules.
REMEMBER: although you have a web page sitting there in your face, THERE is
NO session. Web browsers only look like sessions, the server knows
no history after the fact!
Of course, if the protocol is Telnet, then it IS a session. You are simply
using Netscape as a fancy network menu system, nothing more!
Client/Server rules
-------------------
The HTTP architecture strictly follows a principle of "dumb (meaning no
business rules)" clients and "smart" servers. The Web client is ubiquitous
and good at displaying information on screens in heterogeneous systems.
*** All intelligence about business rules remains with the Web server *** ,
unlike SQL client applications.
In contrast to SQL client applications, any changes to business rules get
implemented on the Web server side of the application - not the Web client
application.
*** This method eliminates the need to update client software *** when
reports are added or changed.
Stateless protocol methods used in this design scale far beyond what a
state-full system would. Because stateless transactions are short and
complete, machine resources are freed to do other tasks between them.
Authenticated and Authorized HTTP Access
----------------------------------------
In NCSA version 1.3 of HTTPD, basic Web authorization consists of defining a
host system "realm" name that is the name given to a particular host Access
Control List file (ACL). Several HTML Hyper links may belong to the same
realm as can several different users belong to the same realm.
When a Web browser requests access to a resource located on the host system
with a protection rule or Access Control List file defined for that resource,
the HTTPD server expects client authentication. Authentication maybe provided
or not provided by the client. When the client does not provide
authentication, the server challenges the client for it.
Server challenge:
"HTTP/1.0 401 Unauthorized -- authentication failed"
"WWW-Authenticate: Basic realm="TheRealmName"
* Client responds with authentication:
Authorization: Basic "encoded_{username:password}_string"
The server challenge method allows Web clients to follow a simple transaction
model by providing the client with security information about the resource.
Sophisticated clients cache security information like username-password, and
indexed this information by the realm name provided by the host system. If
the Web browser navigates a link of the same realm name again, cached security
information on the client can authenticate it without user intervention. The
same idea is applied by the client for multiple caches of different realm
names, as the server requests authentication the client can respond with the
correct username-password string.
Password security provisions on the Web client include:
* Passwords entered on graphical Web clients show as bullets "*****" or echo
suppressed when entered on Telnet Web clients.
* The Web client must encode username-password using the method requested by
the host or the host will return an "unauthorized" status.
Protection rules on the Web server specify such things as valid
authentication schemes, password and group mask files, and password server-id.
Protection functionality includes whole directories, user names paired with
locations (Internet Address masking) and different authentication schemes,
such as basic or kerberos for example. Complete descriptions of WWW security
methods are referenced openly on the CERN or NCSA World Wide Web server
location.
In summary, as a Web browser navigates a secure resource on the host system,
the server challenges the Web client with an "Unauthorized" status. The Web
client's response to the host is one of authentication, i.e.,
username:password string. Sophisticated Web clients' cache username-password
indexed by host realm name. The second time a realm name is navigated, the
Web client responds with a cached authentication string. The HTTP basic
authentication scheme requires Web clients to encode username-password strings
before transmission over a network.
****
NOTE: in order to create the proper HP system log files tracks, it should be
possible to do a "setuid" call within the HTTPD to the authenticated user
contained within the htauthen file? I believe Mike Belshe has stated that
setuid is nothing more than a wrapper for AIFCHANGELOGON. Mike Belshe help
me out!
World Wide Web Client/Server Applications
-----------------------------------------
BATCH COLLECTION:
----------------
A batch collection World Wide Web application is simple. The author
provides all relevant information and the action of the host is simply to
collect it. The collected information could trigger an event, such as an
information package mailed to the address provided on the form.
Using Secure Sockets Layer (SSL) Mcom corp (netscape) expects to provide
trusted connections over an unsecured network, i.e., the Internet. You will
start to see forms that ask for credit card numbers and such. But, I would be
very skeptical about providing anything like that in an Internet Web form
without some sort of "registrar" function, that the site knows MY account
(maybe setup through US mail or a bank) before I provide it mine.
UPDATE: Possible Method of Management of WWW Critical Update Transactions
-------
HTTP authentication solves the problem of identifying a user to a particular
host resource (in this example an executable that updates a data base) but
does little in providing for critical transaction management. Because there
is no state maintained between a "get" action and a "post" action, the host
server must provide a mechanism to simulate a session.
One mechanism to simulate a session while using stateless HTTP protocol
consists of storing an index to host environment information between stateless
transactions. A list of critical environment information that must be kept
about an update transaction between HTTP "get" and "post" actions include:
* Time of creation - the server can impose a "time to live" on the
transaction if it knows the time the form was constructed,
* User name (provided by Web authentication),
* Form name or function, tagged field names used to build form,
* Client location (Internet Protocol Address of Web client),
* Path information - a communications area that stores
information about data base or file positions and contains a copy of the
original data used to build the Web update form (OR a checksum to verify
returned TAG field name data.)
***
NOTE: NETSCAPE solved the "open forever Web form transaction problem" by
including this one extra CRITICAL environment field in their model, which is:
"HTTP_REFERER = http://www.somewhere.edu:80/update_address"
This field is active only in memory at the time of form fetch. The field is
transmitted back to the server on each form posting. The server can check
this variable and determine that yes, indeed, this form came from this server.
There is no timestamp, though. If I save this Web form on disk and reload it
later, HTTP_REFERER field will reflect my disk, not the server!
***
Information kept to verify a Web update transaction can be sensitive and large
making it impractical to encode on the Web form itself. The solution to
keeping information about Web "get" and "post" actions are to 1) create a
transaction index 2) use the index value to reference historical information
about the transaction on the host 3) embed the index value into the Web form
so that a copy is stored on both the client and host.
The transaction index value should have these properties (and maybe others)
so that a reasonably secure index value is generated:
* One time usage (prevents copied or saved forms being posted),
* The index expires after a predetermined interval,
* Tied to an authenticated user name,
* Tied to an HTML resource name or executable,
* Tied to the client's Internet Address,
* The index must be unique, large (>8 bytes) and random.
An example method would be to encrypt a string "timestamp:user:IPaddress"
and encode the result into printable characters,
Note: If a client posts a form with an index value that is not found or
mislabeled on the host (does not include expired indexes), the host should
treat this as an attack. The server should refuse connections from that IP
address for an interval. Also, a log should be kept of attacks on the server
or a message sent to the console.
A method to embed a transaction index value into an HTML body and have the
value returned by an HTML form is to use "hidden" input field types on the
form, illustrated in the following HTML code fragment:
<FORM METHOD=POST ACTION="http://www.somewhere.edu/cgi-bin/update">
<INPUT TYPE=hidden NAME=transaction_index VALUE=xaSPjEbegCx1d5kf>
...
</FORM>
The Web client will not display or label "transaction_index" on the Web form
presented to the user because the type is "hidden." However, returned from
the Web client to the server are the contents of the transaction index field
"xaSPjEbegCx1d5kf." The host Web server can emulate a session by
recreating the environment indexed by the returned Web field value on the host.
Programming a Critical Web Update Transaction
---------------------------------------------
A sample method to program a World Wide Web Get/Post update transaction to an
IMAGE data base Master or Detail set using HTTP methods would consist of these
steps (legend: s* = action taken on the server; c* = action taken on the
client).
Client receives a form from host server:
c* Web client opens connection to a host server,
c* Web client requests address_change form (method=get),
s* Response from host server is "Unauthorized",
c* Web client provides authentication: basic encoded_username:password,
s* Host server grants access to application, indexes environment information,
responds with HTML text that includes a hidden field containing
transaction index,
s* Close.
Client posts a form to host server.
c* Web client opens a connection to original host server,
c* Web client requests address_change (method=post) and authenticates,
s* Server takes actions upon returned data fields from the Web client:
- Verify the transaction index,
- Recreate environment information,
- Update appropriate file data on the host,
- Respond with HTML confirmation document,
- Close connection, destory index.
c* Display document.
Transaction indexes reference environment data and can be stored within
native KSAM files or IMAGE data base sets. Environment information stored on
the host includes any information needed to establish prior file positions and
history. For example, to update records stored within an IMAGE data base I
might store a detail set record number or master set search item value.
Conclusion:
----------
There you have it! I Hope the HTTP protocol is changed to store user info on
the client, where it should be. But this will require encryption methods to
make it secure living on the client. Mcom's encrypted server / client setup
might be the solution to session management, if the server can deposit some
content type string to be returned to the server on the post. If anyone has
ideas on Web session management, drop me an Email.
Hope this helps,
Eric
--------------------------------------------------------------------
Eric J. Schubert Administrative Information Services
Senior Data Base Analyst University of Notre Dame, IN USA
Email: [log in to unmask]
World Wide Web: http://www.nd.edu/~eschuber
|
