Re: Web site authentication

Mike,

We have a combination of things controlling access. First, we have some
sites using basic authentication which has built in support for user
profiles, validation lists, and LDAP (and Active Directory which is
basically Microsoft's version of LDAP). Other sites don't use basic
authentication and use cookies to store a session id which is an MD5
hash of several things that gets validated on every page request. That
way of authenticating can use either LDAP or validation lists.

We do not use user profiles for anything since they are a big security
exposure. As you know, a user profile can let someone gain access
through things like ODBC and FTP (and other things) and if you don't
lock everything down properly, someone could gain access to the box.
Also, there are management issues with keeping track of which profiles
are for whom and there is less flexibility with things like the rules
around lengths and required attributes (number of non-alpha characters,
etc...).

Matt

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Mike Cunningham
Sent: Monday, August 27, 2007 8:18 AM
To: Web Enabling the AS400 / iSeries
Subject: [WEB400] Web site authentication

I am interested in a quick poll on how other iSeries shops who are
developing web applications are doing authentication. Are you using the
built in Apache mod? If so are you authenticating using iSeries
userids, LDAP or Auth Lists? If not using the Apache mod did you write
your own with the same questions on what directory you authenticate
against. Are you using persistent sessions or browser session cookies
to maintain who is doing what?

To answer for myself, we wrote our own authentication process using the
IBM APIs to validate userid/password against iSeries userids but are
going to extend that to also authenticate over LDAP to our Active
Directory tree. We are not using persistent sessions and use session
cookies. The cookie has nothing but a 64 byte string that we create on
logon and keep in the database. Every hit is checked to see if the
cookie exists, has not timed out and who it is associated with.