Is it possible to create own authentication without standard classes and namespaces?

Question

I have created blank Asp.Net-MVC 3 web application and want to write my own very simple authentication. Created a database where all information about users will be stored. Created a controller, view with textboxes for login and password. So now user opens my site, input his login and password, this information is received on server and handled(via my own ValidateUser method). Where should I store information about this user for further using?

If you didn`t understand what I want then the question is: can I implement my own authentication process without using standard MembershipRoles and MembershipProviders?

Definitely should integrate your custom solution with FormsAuthentication bits. If you really want to get blood on your hands, check out [Phil Haack's post](http://haacked.com/archive/2011/10/04/prevent-forms-authentication-login-page-redirect-when-you-donrsquot-want.aspx) — Brett Veenstra, Mar 28 '12 at 12:59
Would writing a custom membership provider solve your problem? Google "Implementing a Membership Provider" http://aspguy.wordpress.com/2011/07/30/single-sign-on-with-wcf-and-asp-net-custom-membership-provider/ — RickAndMSFT, Mar 28 '12 at 17:17

Darin Dimitrov · Answer 1 · 2012-03-28T12:45:32.767

In the controller action to which you are POSTing the login form you could verify the credentials against your database and if success emit an authntication cookie which will contain the username of the currently connected user so that you can retrieve it in subsequent actions.

For example assuming you have a form containing a username and password fields which is posting to the LogOn method:

[HttpPost]
public ActionResult LogOn(string username, string password)
{
    // TODO: up to you to implement the VerifyCredentials method
    if (!VerifyCredentials(username, password))
    {
        // wrong username or password:
        ModelState.AddModelError("", "wrong username or password");
        return View();
    }

    // username and password match => emit an authentication cookie:
    FormsAuthentication.SetAuthCookie(username, false);

    // and redirect to some controller action which is protected by the
    // [Authorize] attribute and which should be accessible only to 
    // authenticated users
    return RedirectToAction("SomeProtectedAction", "SomeController");
}

and inside the protected action you could fetch the currently connected username from the cookie like this:

[Authorize]
public ActionResult SomeProtectedAction()
{
    string username = User.Identity.Name;

    // TODO: here you could query your database to find out more about 
    // the user given his username which must be unique
    ...
}

I don`t know how to manipulate cookies, but will be happy if you could give me some keywords or even links to read about it — steavy, Mar 28 '12 at 12:41
@steavy, to emit the authentication cookie you could use `FormsAuthentication.SetAuthCookie(username, false);` where username is the username of the authenticated user. I would recommend you reading more about forms authentication on MSDN to better understand how it works: http://msdn.microsoft.com/en-us/library/ff647070.aspx — Darin Dimitrov, Mar 28 '12 at 12:44

score 1 · Answer 2 · answered Mar 28 '12 at 12:40

Of course you can - and the answer to the first part of your question is 'it depends'. It depends on how/when you want to use it.

The built in authentication stores a token in a cookie that is used for re-authentication.

As a caveat - you'd need a good reason to implement this yourself - very easy to get this wrong and leave holes in your site.

score 1 · Accepted Answer · answered Mar 28 '12 at 12:46

1

You can write your own custom MemberShipProvider and call your own ValidateUser method.

Check this Implementing a Membership Provider

If you do this way then you can use the advantages like

Redirecting to login page if not authenticated by setting this in config file
After logged in you can use the return url to redirect back to the same page where the user was.

answered Mar 28 '12 at 12:46

Kiru

3,489
1
25
46

You don't even need to do this. You could write something that is more customized and just issue a ticket once you have validated the user. The Membership / Role providers don't work too well with Dependency Injection. – Dismissile Mar 28 '12 at 13:39
1

Good recommendation. The biggest benefit of using the membership/role providers in my view is that they're baked in and well-documented. You're less likely to make critical security errors if you're basing your work on components and documentation that have been refined over several releases. Rolling your own security from the ground up is dangerous business, even if you're pretty confident in your security knowledge/skills. – ajk Mar 28 '12 at 15:47
@Dismissile It is good to leave the security risks to the dotnet framework rather than handling this by ourselves. You are right I too had problem in using DI with Spring.Net http://stackoverflow.com/questions/5991253/using-configurableactivedirectorymembershipprovider-in-spring-net but compromised on other benefits with Membership provider. – Kiru Mar 28 '12 at 17:58

score 0 · Answer 4 · answered Mar 28 '12 at 13:04

Yes, it is entirely possible (we don't use forms auth here).

But; you'd need to take full responsibility for everything, including:

authentication
securely storing/processing some token against the user (usually a http-only cookie)
validation of the token/user against resources
invalidating tokens (either to prevent replay, or as logout)
all caching involved in any of this
and anything that goes wrong (including, but not limited to, a bad implementation exposes a critical security fail) is entirely your fault

certainly very achievable, but needs to be done for good reasons, and carefully.

(what's wrong with ?admin=true, eh?)

Is it possible to create own authentication without standard classes and namespaces?

4 Answers4