RE: Storing encrypted passwords on AS400

> From: Brett Slocum
> 
> This would require all the web users to have AS400 userids (as I
> understand what you're saying). We want to be able to give them web
> access without giving them AS400 access. The AS400s involved are
> behind firewalls and DMZs.

Brett, you're definitely on the right path.  This is the exact setup I
recommend to my clients.  However, I'm still a little vague on the data
access part.  Can you give me a little more idea of your basic
authentication and authorization setup?

For reference, I typically do something like this:

1. Authentication is done using standard HTTP authorization against a
validation list.  This gives me a Web userid of an arbitrary length.  I
can use long names and long passwords, and we can turn on SSL, and
everybody's happy.

2. For authorization, when I go to access the host, I submit a job for
each HTTP session.  A central (and highly secured) program determines
which iSeries user profile corresponds to the Web userid, and submits
the job under that profile.

This program and its file are obviously quite sensitive, and so they get
locked down tightly, but that's easy to do on an iSeries.  The file is
owned and exclusively accessed by a special profile.  That profile also
has *USE rights to those profiles for which it can submit a job (special
profiles like QSECOFR are specifically excluded from that list).  The
submit program adopts authority of that profile when it is called, and
access to the submit program is tightly controlled.

This works wonderfully if I get my data through calls to RPG programs
(which I do, exclusively).  It falls down, though, for JDBC access.  The
problem with JDBC access is that it's not particularly secure especially
if you're using connection pooling.  I'm not sure that, without the
actual password, you can even create connection for a specific user
profile.

Joe