Re: Storing encrypted passwords on AS400

[Brett Slocum <brett.slocum@xxxxxxxxx>]

On Thu, 10 Feb 2005 10:20:09 -0600, Joe Pluta
<joepluta@xxxxxxxxxxxxxxxxx> wrote:
> > 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?

Authentication is done by taking the userid and password from the JSP
and running a stored procedure in the AS400 via JDBC. JDBC is setup to
use one AS400 id in the <webapp>.xml. Each user has a role that
determines if they are a normal user, an account manager (manages
several users), or an administrator. This determines what functions
they can perform in the web app. Only certain tables and stored
procedures needed for the web app are available through JDBC. This web
app is a read-only view of data from another RPG application on the
AS400.

I should not that this is a legacy application that I inherited. I've
been working hard on making it a well-designed application, as it was
a huge mass of spaghetti code. JSPs making direct SQL calls to the
database, JSPs calling other JSPs to do work that should have been in
servlets, JSPs doing massive amounts of business logic, heavy use of
scriptlets, etc. A lack of OO understanding, a lack of MVC or
multi-tier design, and just plain sloppy programming were the causes.
I've currently moved all database access into one object, and now I'm
starting to move logic out of the JSPs and into the servlets. After
that, I'll put in some kind of controller architecture for the
servlets and JSPs. Also, I'm beefing up the exception handling (trying
to get rid of massive use of printStackTrace()), synchronization,
resource cleanup, etc. Luckily, I love refactoring.
-- 
Brett Slocum
<slocum@xxxxxxxxxxxxxx>