Re: iSeries Access for Web -- WEB400

a portion of the current web that pulls info from the AS/400 only works
if the QTMHHTTP is given WAY more authority than it should) among
othre issues.


I solved that problem by writing a plug-in for the HTTP server, and bypassing 
IBM's CGI interface.  This is very important in a setting where security is a 
consideration.  Most applications should run under an individual user profile, 
in secure settings.  IT administrators should be able to see who is running 
what, and how much CPU and I/O they're using, and what locks they've allocated, 
and the time of their last access, and stuff like that.

Web applications may run under various environments (development, evaluation, 
production, etc.) where certain users may only be authorized to certain 
environments. Different environments may even contain different versions of the 
applications. Administrators may want to enable certain environments only 
during certain days, or during certain hours of the day.

Certain users may be restricted to specific client data libraries or different 
physical file members if client data is stored in different physical file 
members. Certain users may be restricted to data pertaining to certain fiscal 
years, where fiscal year data may be stored in certain libraries or physical 
file members.

Web applications may need to be accessible on different domain names, where say 
one domain may be accessible only from a local area network, while another 
domain may be accessible from the Internet, where certain users may be 
authorized to one domain, but not another.

Web applications may need to be accessible from only a menuing system, with no 
option of book marking the entry point, or any other point within the 
application, where certain users are only authorized to certain menus, or only 
authorized to certain items on the menu.

Web applications may need to expose different functionality, depending on which 
menu item it was bound to when the application was launched, or when a user 
accessed the application for the first time.

When sessions expire, users may need to be automatically redirected by to the 
menu. 

Certain users may only be authorized to certain records in a table, or certain 
fields in a record. Certain users may be able to view records pertaining to one 
fiscal year, location code, client, or whatever, but able to update records for 
another fiscal year, location code, client, or whatever.
 
The mechanics of "authorization" need to be easily configurable.

I'm glad that Joe Pluta warns people about ODBC and its close cousins in the 
.Net world, which is essentially based on the premise that security is 
secondary to accessibility.

If users need to query and manipulate data via ODBC, then how about providing 
export capabilities in applications, where users can only export data to their 
PC that they're authorized to? 

The ODBC problem is compounded when talking about environments supporting 
software as a service, where applications are hosted on a single server, but 
support many different companies, where each company needs to be secure. ODBC 
connections require quite a bit of overhead too, especially is situations where 
applications are querying security configuration files to know whether the 
current user has authority to a hyperlink, or authority to a record, field, or 
whatever.

Nathan.


 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com