Securing Your IIS
Web & Content With Access MDB Based User Security
(Simple Yet Comprehensive)
This past week, I sat down to
tackle the chore of securing my personal IIS web server... specifically,
my web app I previously posted here (MP3Tool.Web). It was a learning
experience to say the least, and so I thought I'd zip up my work and share
that experience with the rest of you.
The Chore: secure an IIS web
or entire server via user logins.
The Solution: the magic of
my security approach is achieved by making use of the Global.ASA file and
sessions. As it's name implies, it functions as something of a
global over all the other asp pages on a web site. You can find
documentation on the global.asa posted here on psc, so I won't repeat
those details here (and the rest of this assumes you know what global.asa
is). My security approach makes use of the Session_OnStart on
event. It is triggered the first time a user tries to hit an ASP
page on your site... and occurs BEFORE the target asp page is served up by
the server. This is key to making this approach work. When a
session is first started, a number of activities take place.
1) a connection to the database is established (held as an object
in the session at the top of the page)
2) the "hit"
is logged in the database by IP # and date
3) we test to see if the IP # has been "banned". If
it has, I came up with a pretty slick way to implement the ban.
Attached in this zip is a VB project for my ResponseHelper com object (my
solution to my problem expressed in my previous post, MP3Tool.web, about
streaming back binary data back directly on the asp response). In
this case, we're not streaming back a binary persay, but an HTML page that
looks and works exactly (with 1 smiling exception) to the Server Not Found
page IE serves up. Because I use the com object to stream the file
back, rather than a .Redirect, the end user is none the wiser (their
browser location never changes). =)
4) this part is probably
optional, but then I put in a browser check to ensure that IE is being
used by the client. =)
5) we test to see if a specifically named cookie exists on the
client. This cookie is used to "persist" a user's login...
much the same way your developer login is persisted (if you so choose for
it to be) here on psc.
6) if no cookie was detected, then we test to see if the Login.htm
form is being posted. While the "target" of the Login.htm
page is the Login.ASP page, we actually intercept and process all logins
in the Global.asa file. Login.asp file theoritically should never
actually be hit.