I would just use standard ASP.NET Membership to manage your users - I'm primarily a Webforms developer who has only dabbled with MVC, sadly, but I see it is included if you create a new MVC Web Application project using the Internet Application template.
Roles are managed using the System.Web.Security.Roles class which has simple methods AddUserToRole() and RemoveUserFromRole() that can be used to grant and revoke permissions.
And then your individual pages use the IsUserInRole() method to check whether to allow various actions.
Let me start off by saying, "I feel your pain, brutha." I went through this 3 years ago, and I wish MVC had matured at that point because the WebForms solution I designed fairly well resembles the MVC model without actually having the Microsoft libraries built for me (of course, there were several glaring "Why the hell did I do that" differences).
I also ended up using iFrames to manage the content differences using .Net as the parent application and classic asp as the slave. I developed the framework architecture in .Net and implemented that. The classic asp pages were then "culled" of unnecessary presentation pieces (includes and whatnot) and loaded into iFrames. Data was then passed in through the url using a custom encryption. To make sure that the authentication could not be spoofed easily and the page accessed by cracking the query string we also employed Wildcard handlers in IIS that forced .Net to authenticate before parsing classic asp pages.
Given that, my recommendation would be to head to MVC straight away.
- MVC will give you access to routing at the global.asax level. With clever manipulation of a controller, you could develop your models in a proper fashion and have a common controller that handles all classic asp requests as necessary.
- MVC will make it very simple to add a test project and allow you to refactor individual application pieces based on the new model structure while providing adequate test coverage to make sure you're getting it all right. The value of this is absolutely incalculable because in any refactor code coverage is a huge concern.
- MVC follows a more scripted approach to presentation than WebForms does. WebForms tries to mix it all up like it's some kind of stateful application (which it isn't), and that can be quite a culture shock for people accustomed to classic asp. Don't get me wrong, your developers are going to have culture shock no matter which way you go, but if you can take some of that shock out of the presentation layer you might find greater success.
I like both WebForms and MVC (though I'll admit with the introduction of Razor I'm becoming a little biased towards MVC). They both have their places, and I think an application such as the one you describe may be ideally suited for an MVC implementation particularly given the "staggered" nature you'll need to adopt in rolling out refactored application pieces.
Whichever way you go, I think you need to make sure that the .Net application is always the parent application when it comes to authentication/authorization/routing/etc. A colleague of mine implemented his migration on a similar application with classic asp as the parent, and he had a large number of problems when it came finally to integrating everything back together.
Best Answer
I think if you are talking performance like efficiency of HTML generated, speed the page is returned, etc., it doesn't matter which framework you choose. It matters which developers are on the project. You can make a speedy website with either framework, and you can make a horrifically slow website with either framework.
That said, I believe MVC makes you a little more aware of the content you are generating, and the tasks you are performing on the server, and this awareness might make the developers more likely to pay attention to performance, thus resulting in a faster site. But this is a side effect.