1

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.

Kev
  • 118,037
  • 53
  • 300
  • 385
YvesR
  • 5,922
  • 6
  • 43
  • 70

1 Answers1

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.

Paul
  • 35,689
  • 11
  • 93
  • 122
  • Well I thought about it, too, but I really need basic auth at all for some application reasons. You wrote that I use a encrypted cookie or session, that is exact the point, it is possible to store information in a likely session/application scope? – YvesR Jan 08 '11 at 16:14
  • yes, you can use session or app scope; I'd probably use session for this. – Paul Jan 08 '11 at 16:17
  • when i access the HttpApplication application = (HttpApplication)source; HttpContext context = application.Context; var test = (String)context.Session["LCID"]; I get a null reference, so it seems there is no session available?! – YvesR Jan 10 '11 at 17:06
  • I have no idea where in the code you are. You said you're in a module? the module should have access to the app as a parameter, see here: http://support.microsoft.com/kb/307996 – Paul Jan 10 '11 at 18:36
  • I don't have a session because in my case (using old classic asp app after auth) I just had application_start event. So I decided to store encrypted data there, that works fine to me, so my problem is solved at all. Learned a lot about modules now at all, so thx a lot to all that helped me. – YvesR Jan 12 '11 at 10:52
  • ah... I had no idea you were using classic ASP in the mix, that definitely changes things. Glad you worked through it, though! – Paul Jan 12 '11 at 18:47