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.