I have checked the following article on how to use the sqlMembershipProvider. My question, is this the way most of the asp.net applications authentication schemes implemented.
Is there any other method, any references will be quite helpful for me.
Edit1:
My intention is to know the other possible ways, I can authenticate a user against a standard database.
"Most" is unfortunately hard to quantify.
MSFT has made it easy to setup an ASP.NET application using SqlMembershipProvider for an out-of-the-box setup, making it super easy to get authentication against a SQL db working.
That said, I rolled my own, because I didn't need much of what the built-in stuff was doing.
The way I did it was to write my own membership provider class, and use the web.config to specify that my customprovider was the default membership provider.
For ASP, there are other ways of doing authentication, such as using NTLM (basically creating windows users for each web user, and using Windows built in authentication).
Short answer: If you can make use of SqlMembershipProvider, and it does all that you need, then I recommend using it.
I reckon #Alan (+1) makes good points.
On a simple level if the (trusted) framework you are using offers you a solution that needs configuring rather than coding and it covers your needs unless there is a compelling case against it then it is probably a good solution.
You wouldn't write a new textbox control in asp.net, or a new fadeOut method for jQuery - you would use the provided solution.
I've rolled-my-own in this area and used all kinds of plug-ins and third-parties over the years. But in the project I'm currently working on we needed user authentication on Tuesday of last week and with SqlMembershipProvider the security module was complete by Wednesday. That's good enough for me!
Related
I am a complete beginner in ASP.NET and looking for a simple example that makes use of authentication and authorization. (Form authentication)
I have looked around and there are so many different ways that it's being done.
Like ASP.NET membership and ASP.NET login controls.And then there is another way Asp.net Identity
If anyone can provide a good starting point.
This answer is based entirely on the fact that you are new to ASP.NET
My recommendation would be to look at the ASP.NET Identity setup. You can easily set up users, manage their roles, and do most of the difficult work using Identity. There's still be some manual work involved but you'll get to learn the basics and in production it can still be quite a powerful tool. Most of the products I have created or used have all had an Identity backend for their user management. Once you've become quite advanced in ASP.NET and understand how it works, you'll be able to look at other options along with their benefits and downfalls over Identity. But until that time, stick to the Identity framework. Should you get stuck and need help, you'll find plenty of online support and a large community of people who understand it enough to help you solve your problems (which might not be the case with other frameworks).
I'm hoping someone can help me wrap my head around what's going on when I try to implement a custom MembershipProvider. This is probably more of a theory question than a code question...here's what I have:
MVC 2 app (started from an empty MVC 2 project)
SQL Server DB with my own "users" table
A User class, UserRepository, UserService, blah blah blah
Currently, my application authenticates via the UserRepository which returns a User object if successful. This User object is then stored in the session and is subsequently interrogated by all controller actions that require authentication.
Now...I understand that storing this in the session leaves me vulnerable to session hijacking and that a more secure method would be to implement my own MembershipProvider. What I don't understand is, where would this custom Provider end up storing my User object? I see that the overridden ValidateUser() method just returns a bool, but I can't figure out where that information is persisted for that user's time on the site.
I'd really like to keep my existing process while making it more secure by taking away the dependence on session for user authentication. I like having a complete user object at my disposal throughout the application once the user is logged in, but I'm open to suggestions otherwise. It seems that a lot of the MembershipProvider documentation is kinda black-box. I'm hoping that someone can explain what it's actually doing under the hood to persist user authentication.
Thanks in advance
Once a user is validated ASP.Net Membership creates a token (a large encrypted string) that is stored as a cookie or as part of the URL string depending on how you configure it in the config. It can optionally do either based on whether cookies are available or not. The token is used to persist the identity of the user to answer your main question about how it works at low levels. Everything else associated (roles, profile, etc) is retrieved from the server depending on how the custom provider is implemented.
It's not necessarily true that this is more secure than session - it has the same vulnerabilities of URL or cookie replay if the site is not protected by SSL encryption (worse with URL in case the users email around url's to others).
Take a look at the way Microsoft did there's they released the source
Provider Source
Also remember nothing is a black box in .Net you can use Just Decomile or reflector to learn more about how others(Microsoft) have done the same thing you want to do.
Aside from all the answers, I believe the missing link in your post is ASP.Net Forms Authentication - this is actually what uses ASP.Net Membership in an ASP.Net web application.
So if you have your own db and auth scheme (already) in place, you can use Forms Authentication with it - even without trying to make it work with Membership (you really don't have to).
Here's (quickly becoming my most used link) an overly simplistic MSDN example of Forms Authentication with the scheme hard coded. It shows you that you can even do it that way - not that you should of course, but just shows you the possibilities.
As all the answers above have stated, you can build your own provider if you require. The farthest I've gone (so far) hasn't been to build one, but just customize a few methods. Reason: the existing user db of a project I had was using MD5. This meant I just overrode 2 methods (if memory serves that is) - ValidateUser() and CreateUser()....
Hth
Here's an excellent tutorial on implementing your own custom MembershipProvider.
http://www.codeproject.com/Articles/165159/Custom-Membership-Providers
That being said, you really need to read the article. Once you read the article and follow the steps, you'll start to understand the answer to your questions. There's really not a great way to understand it other than going through the drudgery of following a tutorial like this. At least, that is my opinion. I just implemented my own custom membership provider for the first time by going through this tutorial. After a few hours, I was able to start implementing my own encryption algorithms.
I would highly recommend using the standard Membership Provider but creating a link table to join your existing user repository to the asp net membership provider. Best of both worlds.
We are currently building architecture for thin-client bookkeeping application. It should follow two main requirements:
Application should have module design. Each module can have (and they actually do have) own Role system.
Later application should be adapted for running using different databases on different machines.
We think Asp.NET MVC 3 is appropriate platform for this task. For managing application data we chosen latest version of Entity Framework - its batch of Data Providers and Code First feature can save us much time.
The part we are tangled with is user/role management system. We should have some kind of Global Administration section for adding users and giving them access to modules (only global admins can add user to the system, no "guy from street" registration supported) and each module has its own administration section with its own admins and roles. We already have data model to store everything we need in appropriate way but have no idea how to access this data correctly from application.
Currently we see two possible ways to resolve this problem:
To write custom Membership and Role providers based on our DAL. Nobody from our team have done this before so we are not sure if this way worth the trouble. Membership provider cant offer as much flexibility as application needs so some crunches would be needed.
To dig through some obsolete books to find out how web sites administration system was organized before Membership providers where created.
Both this ways are not elegant and not obvious for us and its not an easy question which way to choose. Also we do believe that it can be other solution (of cause architecture can be affected). So, we would be glad to see any suggestion connected to this problem.
I'd personally recommend using the standard membership provider for creating and authenticating users in the first place, and then once you've verified that the user isn't just some "guy from the street," use your own custom architecture to verify that the authenticated user has access to the controller and action that they're trying to access.
The built-in membership provider takes care of a lot of nuances with regard to user authentication, password storage, and such. It uses best practices to avoid brute force attacks, rainbow table attacks, etc. It's tried and true.
But it sounds like your per-module permission structure may or may not fit the mold of the ASP.NET Role Providers. If they do, that's all well and good, and it'd be a good idea to implement a custom role provider. But if your needs are "outside the box," you'll probably be better off just manually checking rights at the point that's most appropriate for you (controller, action, request filter, etc.).
I would encourage you to use a custom membership provider. Why? Cause its the standard way and will save you tons of works. It's not as hard as I might see and there are tons of resources like this one.
To write custom Membership and Role providers based on our DAL.
Nobody from our team have done this before so we are not sure if this
way worth the trouble. Membership provider cant offer as much
flexibility as application needs so some crunches would be needed.
It is very much worth the trouble, if the default ones do not provide the functionality you need. If you already have a complex user system in your database, a custom membership provider is probably a good idea.
It will add valuable experience to your team, and you should be able to reuse much of the code in your next project. As #Randolf mentioned, there are loads of good resources for building a customer Membership provider, and I speak from some experience when I say that it is not really all that difficult. Everything is there, you just need to implement some methods.
Well, finally we decided write all from scratch and it was easier that it seemed to be
Add own IPrincipal implementation. Additional fields and completely different logic for IsInRole() method to avoid writing own attributes.
Assigning our IPrincipal in Global.ajax event to User.
It wasn`t hard at all. Now we have all the flexibility we wanted. No providers involved.
Looking to implement authentication/authorisation for ASP.NET app
Was looking into using Provider model MembershipProvider SQLServerMembershipProvider etc as makes good sense to me.
However I'm looking into the Enterprise Security Application block as well. My question is can/should the two be used in tandem?
Enterprise Security Application block provides you the facility to choose your Authorization Rule Provider and it can be configured to use the MembershipProvider. So yo your question, You can very well use ESAB in your application if you looking for layer agnostic authorization. Still you will need to use your preferred Authentication mechanism in ASP.NET (Forms/Windows)..
In other words: if you have sufficient time you can use ESAB. For a rapid development scene, go ahead with MembershipProvider and customize it to suit your needs. ESAB is more appropriate for enterprise level applications where you not only need authentication/authorisation but also caching.
Is there a standard object I should use to edit Users and their Roles in ASP.NET? Or should I role my own?
This is one is fairly feature rich and well documented...
http://mywsat.codeplex.com/
What about following classes
MembershipUser
MembershipProvider
EDIT:
The Roles frameworkâs functionality is exposed via the Roles class, which contains thirteen static methods for performing role-based operations.
CreateRole and DeleteRole methods will do the job.
Reference : http://www.asp.net/learn/security/tutorial-09-cs.aspx
If you need a custom implementation of the built-in functionality that you can modify to suit your needs you can find one here
There is a built-in web site administration tool that works well locally: http://www.developer.com/net/asp/article.php/3569166/Configuring-Your-ASPNET-20-Site.htm. This shows an IIS administration tool, but I have not used that so I don't know how well it is. But that again would require logging into the server.
For our app, we built our own because we needed something more robust anyway, at least for the users/roles part. I haven't seen anything personally. You could try checking out the codeplex.com site, I remember seeing some things in the past, but never researched/experimented.
HTH.
Use the standard Membership and Role providers framework for the backend. There are two out-of-the box Membership providers that handle authentication against the DB or Active directory (SqlMembershipProvider and ActiveDirectoryMembershipProvider). There are a couple of out-of-the box Role providers as well (SqlRoleProvider, AuthorizationStoreRoleProvider, and WindowTokenRoleProvider).
For the front-end, the Logon controls are standard and interact well with the Provider framework...but only for login and changing passwords.
To my knowledge however, there are no standard GUI controls or wizards that have out-of-the box functionality for editing and administering users. You'll have to roll your own pages for that.
I wrote a couple of custom aspx pages.