How the IIS7 handle a auth module? Memory scope?

Question

As those who have worked on such a project you probably know this site:

Developing a Module Using .NET

In this article Mike Volodarsky created a very good post on how to create your own security authentication extension for the IIS7.

I took this and modified to my own need. I am fetching the basic auth credentials and call an external web service to authenticate the user from a different active directory domain.

This in principal works fine so far.

Calling the web service takes some time and each request, site, resource (image, stylesheet, javascript file, etc.) causes IIS7 to call the module and authenticate again.

I am not aware how the IIS7 handles this module so I decided to create a sql-table based security token with a ten minutes lifetime. So now my code checks if this token is available and grants acccess or if not, call the web service to authenticate again.

I developed everything and it works well. In production I ran into worse timeouts and found out that my sql connection is the problem. The connection pool overloaded. I fixed this with a bad workaround to set the pool size to very large number.

Now here is my problem / question:

Does anyone know if this module will stay in memory in any way so I can store a token in memory - application pool scope? The idea is to store the tokens in memory while the application runs. But I can't find any information to help me to find out how the module is handled in IIS7 and if my idea is a solution for the problem.

Answer 1

You wouldn't keep the module itself in memory, but what's common would be to use an encrypted cookie or session to maintain the creds. It sounds like you're conflating problems a bit, though. Your module sounds like it can (and should) be handled by a custom Membership Provider, nto a custom authentication module.

Assuming (based on your post) that you're taking a person's username and password over the web (ostensibly from a web form), you should use the Forms Authentication provider in ASP.NET, and then implement a customMembership provider for doing the actual creds checking. The Forms Atuh provider can then handle maintaining the auth token between your app and the user's browser.