As those who have worked on such a project you probably know this site:
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.
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.
preguntado el 08 de enero de 11 a las 16:01
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.