Session management with ASP.NET MVC + IIS 6.0 + Basic Authentication

I'll soon be embarking on a dev project with ASP.NET MVC (C#), but would like to first determine how to fix some of the shortcomings of our existing ASP classic applications in the new environment. Our intranet web servers are running IIS6 and for some reason (apparently due to the load balancer) the IT team has determined that Windows Integrated auth won't work and so we're stuck using basic. I'd love to do forms-based and query the AD, but that's not an option for security purposes. So the challenge is to mimic what can be done using forms-based authentication, but while actually using basic. In particular, being able to do something at least approximating logging out would be beautiful. The IT team's lead web developer said he gave up on trying to get that to work. It seems there's a lot of information on this out there, but much seems to be conflicting due to variations in configuration.

Is there a best practice to achieve this, given our configuration?

So far the best I've found would be to just do some kind of manual session tracking and then prompt for log开发者_运维知识库in info again by responding with a 401 if the 'session' has timed out, or if they had been marked as logged out and then visit the page again before closing and opening the browser. It seems like that would work, but is there a more elegant solution?

One small point: Authentication and Session are two different concepts in ASP.NET, although the terminology lends itself to them being easily confused.

Authentication has an authentication ticket encrypted in a cookie and this usually has a time limit for how long you are logged into the site before you need to re-authenticate. This may also be a sliding scale, or never require you to re-authenticate, depending on how your authentication is configured.

Session is the data held in Session state for a particular interval (authenticated and unauthenticated) and is tracked by its own cookie. Depending on how session and authentication are configured together, it is possible to have scenarios where a user's authentication interval elapses, requiring them to log in, and yet they still have session data and vice-versa.

It sounds like you're talking about an intranet application based on the fact that you'd like to use Windows authentication and Active Directory to authenticate users and authorize what those users can do in the application. That can work very well for an intranet application and I'm not entirely sure what the security concerns have been voiced about this. Could you elaborate?

If you're talking about an internet application and would like to use Windows authentication and Active Directory for intranet users and forms authentication for anyone else, then this can certainly be acheived too. You may want to take a look at Windows Identity Foundation to achieve this.