views:

724

answers:

5

The website I'm developing will allow users to login at 3 levels.

Level 1 - Not logged in

Level 2 - They register their email address and receive a confirmation email, and login that way.

Level 2 - They login with a username/password, which is then sent to a web service. If the web service comes back with a "successful login" result, they're logged into the website.

Depending on the login level, some web pages will be available while others will be restricted.

My question is, how should I develop this?

I'm doing the project in ASP.NET MVC.

Should I just code my own AccountController? Should I use .NET Forms Authentication? What's the benefit of Forms Authentication over just doing it manually with .NET code?

If I did this myself, on successful login, I'd just store the logged-in user in a session variable. Is there any harm in doing this, or for what I'm doing, is it OK?

+1  A: 

I would recommend strongly against rolling your own authentication system. .net Forms auth is so easy too use; why would you waste time building it yourself? There are many many pitfalls to authentication systems and unless you are MS you really don't have the resources to build and test one.

Determining what pages the user can see is authorization and that you certainly can code your own way. I would suggest looking into the Identity/Principal interfaces that are available in .net and override the "IsInRole" method to suite your needs.

Sessions are not really good for security. They don't work well in web-farm scenarios and when the app pool decides to recycle...all your users are logged out. .net forms auth uses cookies by default.

DancesWithBamboo
I's say it's much easier to roll out your own system than trying to understand how ASP.NET membership works. Moreover, I don't want literally hundreds of unnecessary tables, view and stored procedures supporting ASP.NET membership to reside in my database.
User
A: 

In your case, I would recommend using simple Forms Authentication. (See How to: Implement Simple Forms Authentication). A simple LoginController could handle this.

There's nothing "wrong" about storing user profile data in the Session, but this can lead to scalability issues if you ever need to load balance your web site. The recommended method is to implement a custom RoleProvider. (See Implementing a Role Provider.)

As for access control, perhaps you can have a BaseController class that checks the user's current role to see what kind of access they have.

davogones
+4  A: 

Hi, check this previous question in SO:

How should I implement user membership in my ASP.NET MVC site?

Check out this blog on ASP.Net MVC Membership Basics.

Ric Tokyo
A: 

(based on ASP.NET 2005)

I used the Login control which is part of the ASP.NET Webcontrols. This onject can be added via the toolbox under Login.

You could then take the username and password and check to see if that user exists, then set the authentication property to True if successful. You will then be taken the what stored in the DestinationPageUrl.

e.g rough code snippit...

' Store the username and password from the Login control
Dim lstrUserName As String = logLogin.UserName
Dim lstrPassword As String = logLogin.Password

' Call some function here to check to see if the username and password is valid
CODE HERE

' If success
If lintResult > 0 Then

   ' Clear and set up session variables
   CODE HERE

   ' Pass login details to a cookie in case you want you remember the 
   CODE HERE

   ' Successful Login
   e.Authenticated = True

else

   e.Authenticated = False

End If
kevchadders
+1  A: 

I would suggest that the best way of writing your own custom membership/authentication system is to actually use the built-in MembershipProvider class in .NET, and deriving your own custom class from that. You can always create your own Membership Provider by inheriting from the System.Web.Security.MembershipProvider (and Role and Profile classes, too!) class within the .NET framework, and provide your own specific implementation. This way, you get the benefit of using a solid and reliable "base framework" upon which to build your authentication and authorization system.

By deriving your custom Membership Provider by the framework's own base class, you get to leverage many of the great features of ASP.NET's membership system that are built-in, such as declarative authorization in the web.config file and the built-in ASP.NET authentication tickets. I answered a very similar question here that details some of these benefits.

I must admit, one thing I did find unusual by it's omission in the "standard" built-in membership providers in ASP.NET was the lack of a simple way of allowing users to register with a website but not to "validate" their account immediately, but rather send the user an email containing a "validation link" that they must click before being allowed access to the website. Whilst this is not a standard feature within ASP.NET MembershipProvider class, it is relatively easy to implement.

There is a great series of articles by Scott Mitchell regarding ASP.NET's Membership, Role and Profile providers (including one on validating an account via email before allowing login) which can be found here:

Examining ASP.NET 2.0's Membership, Roles, and Profile

which should help if you derive your own custom provider from the ASP.NET providers.

CraigTP