Ken ng <ken @
helios .
njit .
edu> queried the List, looking for a boxed
solution:
>The client has a lot of field agents, and would like to make information
>available to them whever they go over the internet. But, the information
>is sensitive, so just putting it up on a WWW server isn't enough.
>
>They have the sensitive information on an Oracle server that is entirely
>within the company. All the agents have SecurId cards. What they would
>like is to have web browsers do encrypted SSL/HTTPS connections to a WWW
>server, authenticate with SecurId, and do the queries that way. The WWW
>server is a front end Oracle querying device that talks encrypted SQLNET
>back to the server that is safe inside of the company.
<<snipping a nice graphic and additional info>>
>What I need is that box marked XXX
One XXX option: A couple months back, SDTI quietly introduced a new
feature set called WebID, integrated into their ACE/Client for Win NT
(4.0). WebID supports a demand for two-factor (SecurID or SoftID) user
authentication on HTTP calls to any particular directory or object (page,
or a subset of a page) on a web server. SDTI's first implementation of
WebID was for Microsoft's IIS web server on NT 4.0 hosts, but others are
reportedly in the works.
SSL can, of course, secure the link from the browser to the web
server; but perhaps more importantly, WebID can be set up to _require_ an
SSL link before it allows access to protected resources. (If you use a
firewall in front of your web server, as some do, you'd have to tunnel SSL
through to the IIS.)
SDTI put a hook in ISAPI, the IIS programming interface, to
intercept calls to a protected object or directory. Those calls are
shunted to another page which requests the SecurID token-code and PIN (or
the encrypted combination of the two, from a PinPad SecurID or a SoftID.)
The ACE/Client then authenticates the user against the ACE/Server -- and,
upon approval, gives the user's browser a limited-use cookie which allows
for a continued authentication of subsequent HTTP calls to protected
objects on the same web server. It becomes a pseudo-stateful session.
Secured and public pages can be offered on the same web server; and the NT
Event Viewer collects audit data on all attempts to access the protected
resources.
The back end of your project needs a soothsayer. Oracle's web/RDBS
connectivity is a very dynamic environment right now, with the Web
Application Server 3.0 due out in a few weeks; a library of dynamic
"cartridge" designs being unveiled; and new offerings for both Unix and NT.
Someone would have to know a lot more about your client's needs to make any
suggestions. Note, however, that Oracle's Universal Application Server
uses its ORB to support both a Web Request Broker -- for managing HTTP (off
IIS, among other web servers) -- and a Connectivity Broker, optimized for
managing SQLnet (multi-threaded, and presumably encrypted.)
All of these webbed contraptions, I expect, would sit outside your
client's secure network and they would only draw upon the internal Oracle
database from within a secure pipe, and through the main corporate firewall.
Bonus points: As you move forward, you might keep an eye on RFC
2069, DAA (Digest Access Authentication in HTTP.) DAA was recently
proposed as a replacement for HTTP 1.0 Basic Authentication, which
transmits "snoopable" UU/cleartext passwords. Admittedly not as secure as
SSL (but without the trans-border crypto politics,) DAA proposes an HTTP
server challenge, a nonce; with an MD5 response to hide the user's name and
password.
With ACE/SecurID in place, this may not appear to be directly
relevant to your situation -- but RFC 2069 also allows for an optional
second message digest to guarantee the integrity of an HTTP object or page
being downloaded. (This may be the first provision in an IP protocal to
block IP Splicing or "session stealing" -- and without encryption!)
Some guys at Oracle have put some thought into how DAA might be
used. (Check out, "An Authentication Model," a white paper somewhere on
their <www.olab.com> website.) It might be worthwhile to have one of them,
or a web-savvy Oracle SSE, walk you through some of the DAA's potential
ramifications. DAA is actively supported by NCSA, Spyglass, and Apache
today -- but there is no word yet as to when, or whether, Netscape or
Microsoft will support it (although their folks helped draft the rfc.)
Hope some of this is helpful, Ken.
Suerte,
_Vin
Vin McLellan + The Privacy Guild + <vin @
shore .
net>
53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
|
|
