I'm wondering what the best way is to implement custom security in an
application (IIS, MTS, VB, SQL7).

Sometimes security is implied through business rules. For example, a user
can edit an employee's pay history if that employee belongs to a payroll
managed by the user.

Other times, it's granted explicitly. An employee doesn't manage a payroll,
but someone with the authority to do so has granted that person permission
to update the pay histories of a given set of employees, either based on
their presence on a payroll, or perhaps their work assignments, etc.

Approaching this straightforwardly,

In an application where security has many manifestations, combinations and
exceptions, it seems to make sense to try to formalize the way this security
works and centralize it. And, if possible, to data-drive it so that changes
to the security structure itself can be affected without changing code.

Has anyone out there attempted something like this, or at least given it
considerable thought or study?

At the highest level, at what point would you integrate security into the
rest of your application? What might calls to the security system look
like, and where would the calls take place? Would it be best to implement
it as deeply and transparently as possible, and signal access violations by
raising errors? Or should the security system be visible to the application
and permit direct calls from the application code?

I'm considering requiring the userid as a parameter in every call that
accesses sensitive data (which is most of it in this particular case), and
then determining whether it's a proper call at some level below the first
line of business logic components.

For extra credit, ideally, this would work in a way that would allow ASP
developers to access our first-line business components directly through ASP
code without allowing them to circumvent the security system. So, if these
business components simply took a call like:

payHistory.GetForEmployee(userid, empid)

....the ASP programmer could impersonate any user by supplying an arbitrary
userid in a short ASP page. (userid identifies the user of the application,
and empid identifies employee whose pay history we wish to retrieve).

Incidentally, using NT security will not be an option. Users will be
required to log into IIS, but in some cases they will be using generic
accounts.

Any thoughts or comments?