RE: QUSER on ODBC requests -- MIDRANGE-L

> From: rob@dekko.com
>
> Everyone may rant on how hard coding user id's and passwords are
> a bad idea
> but there are some applications where this is a necessity.  Well,
> I suppose
> you could put them in a dataarea or some such animal but you get the same
> results.
>
> For example, you want to do some batch ftp between one system and another.
> Remember I said batch.  And you get this EDI process that runs unattended.
> I have no urge to hire someone to key in a userid and password.  If I did,
> I'd make the poor bugger click on icons or some other worthless
> application
> to look busy.
>
> Again,  I have a Domino application which gets data from the 400.  The
> people running this application sometimes don't even have iSeries
> passwords.  Are you saying that instead of just clicking on a button to
> retrieve the data, that now I should also pop up a box that prompts them
> for an iSeries user id and password?  Ludicrous!

There are two kinds of data: secured and unsecured.  Examples of unsecured
data are public web pages and the data they display.  Now, if you have a
Domino application that is designed to access AS/400 data, you have to
decide whether the data is secured or unsecured.  If the data is, for sound
business reasons, meant to be unsecured yet hosted on the AS/400, then by
all means create a user profile with access to the data and make the user ID
and password public.

However, in order to create any kind of "public" user profile on your
machine (such as a public demo user ID), there are a number of steps to take
to make sure this doesn't breach your security.  You must make sure that
this user profile is highly limited to only the data it is intended to
access - for example, set the initial program to *SIGNOFF.  Make sure you
have a real security policy in place, with *PUBLIC authority set to *EXCLUDE
on all your objects and authority granted solely through group profiles.  If
you are using this "public" profile for FTP, you may also want to write an
FTP exit program that further secures and limits the requests - for example,
specifically disallowing remote command calls.

A rather more secure answer to this thorny issue is to have a staging area
in your demilitarized zone.  Put a Linux or Windows machine on your network
and transfer "public" data to that machine.  There are a number of products
that will perform this sort of mirroring.  If you prefer, and if your data
is relatively static (that is, data can be updated nightly or even hourly)
you can roll your own data mirroring product without too much effort.
Transfer to the staging machine is entirely under the control of the AS/400,
in a "push" rather than "pull" communication, thereby ensuring that the
AS/400 is secure.

This can also be usd for batch transfers into the AS/400, although it's a
little more work.  Not much - one very simple solution involves a data queue
and the Java Toolbox.  And it's far more secure than just allowing someone
to pump data onto your machine.


> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."
> Benjamin Franklin

I might paraphrase this: those that are willing to give up essential
security in order to make their job a little easier deserve neither security
nor a job.