I'm not very experienced at using ASP.NET, but I've used built in membership providers for simple WebForms application, and I found them PITA when trying to extend the way they work (add/remove few fields and redo controls accordingly).
Now I'm preparing for MVC (ASP.NET MVC or Monorail based) project, and I'm thinking - is there a better way to handle users? Have them log in/log out, keep certain parts of the site available to certain users (like logged in users, or something similar to "share this with friends" feature of many social networking sites, where you can designate users that have access to certain things.
How best to acheave this in the way that will scale well?
I guess, I wasn't clear on that. To rephrase my question:
Would you use standard ASP.NET membership provider for a web-facing app, or something else (what)?
The Membership Provider in ASP.NET is very handy and extensible. It's simple to use the "off the shelf" features like Active Directory, SQL Server, and OpenLDAP. The main advantage is the ability to not reinvent the wheel. If your needs are more nuanced than that you can build your own provider by extending overriding the methods that the ASP.NET controls use.
I am building my own Custom Membership Provider for an e-commerce website. Below are some resources for more information on Membership Providers. I asked myself the same questions when I start that project.
These resources were useful to me for my decision:
Writing a Custom Membership Provider - DevX
How do I create a Customer Membership Provider - ASP.NET, Microsoft
Implementing a Membership Provider - MSDN
Examining ASP.NET 2.0's Membership, Roles, and Profile - 4GuysFromRolla
Create Custom Membership Provider for ASP.NET Website Security - David Hayden
Setting up a Custom Membership Provider - Channel 9
I personally don't think there is a need to use something other than the builtin stuff unless you either want to abuse yourself or your needs are impossible to satisfy by the builtin functionality.
Have you considered using ActiveDirectory for this? Or, perhaps, OpenLDAP? You can manage each user's groups, permissions, 'authority', and so on.
keep certain parts of the site available to certain users (like logged
in users, or something similar to "share this with friends" feature of
many social networking sites
I guess you must custom code your thing.
I also do not like the asp.net Membership and custom code my membership needs...
A nice membership provider is a really missing thing in asp.net side...
It depends.
If it's an internal application, Active Directory or OpenLDAP might be the way to go.
If it's a public application, I suggest to look at aspnet_regsql. You will be able to setup a database with Authentication in no time.
Related
We have used ASP.NET Identity Management in a website. It is used to authenticate users as well as manage their Roles to access specific functionality of website.
My question, Is Cognito something that meant for similar purpose? Can it replace ASP.NET Identity Management? Does it hold functionality for creating, managing and assigning Roles to users to access specific features/pages of my website?
Thanks for any help.
Overall, the functionality is very similar although there might be some subtle differences. Cognito allows you to add authentication to your application. And with the new groups feature, it allows particular users to have access to specific resources.
I am trying to re-learn ASP.NET and building some application, however tutorial seems to be running shorts.
I understand ASP.NET comes now with built in membership which allows users to created and edit, login to users. However, is there a way for me to create a User Controller. From what I have read, its a big no, because it may conflict with the AccountController. Maybe this is wrong, but I would like to be sure first.
Also I understand that I can use the word [Authorize] in a controller ( action, or class ) to limit access to users. However if I provide [Authorize(Roles="Admin")] How can I define the roles to a users? Is there a field that already exists in the membership providing this or do i need to supply a second nuget packages. If its a field from the user, how does it know Roles is the value in the User tables?
You're confusing multiple things. Asp.net is the basic web technology, and there are three technologies that sit on top of that. Webforms, Web Pages, and MVC.
Membership has been a part of asp.net since Version 2, released in 2005. This is nothing new. There has been much written about it over the years.
If you're using MVC, which it seems you are, and you're using MVC4, then the default internet template uses SimpleMembership, which is not compatible with the built-in membership editor in Visual Studio (known as the Web Site Administration Tool or WSaT). This is only compatible with the old SqlMembership database tables, and SimpleMembership does not use those tables.
You can use SqlMembership with MVC4, but you have to configure it to use SqlMembership. Or, you can just not use WSaT and configure your user yourself.
Oh, and don't listen to people that tell you to create custom membership providers. This is the worst advice possible unless you know what you are doing, because it's non-trivial to create secure password hashing techniques. And 99% of people that try (even people that should know better) get it wrong unless they pay very close attention.
Use a provider from a reputable source unless you have VERY good reason not to. And then, check, double check, triple check your hashing code and then have an expert check it.
For Authentication and Authorization in asp.net, have a look at Forms Authentication and Membership Provider (and Role Provider for roles)
A quick search gives this article: Here
have a look at other searches for "Custom Membership Provider"
This also looks interesting: How do I create a custom membership provider for ASP.NET MVC 2?
I'm currently developing a web application that will use Facebook as a authentication service. Does it make sense to implement it as an ASP.NET Forms Authentication custom membership provider? While I made my research, I didn't come across any concrete significant advantage of using the Forms Authentication. However, it instinctively seems to me as a good thing to do, because aside from creating a completely custom implementation of authentication using Facebook, I didn't find any extensibility point inside ASP.NET where I could plug in the Facebook auth behavior.
Can you then tell me whether the Forms Authentication is a good idea or not. And if not, is there any other way than completely custom code (I'd like to avoid managing the session cookies, loading the current user, etc. manually).
I'm using ASP.NET MVC 3, Entity Framework and I'd like to avoid the Facebook C# SDK (the extensive use of dynamic types is a bit of a turnoff for me :-) ).
Thanks for any advice.
A simple answer is to use .NET 4.5 oAuth templates, they are incredibly easy to link Facebook up to forms authentication.
http://www.asp.net/vnext/overview/videos/oauth-in-the-default-aspnet-45-templates
However you may struggle to find a decent server if you are planning on releasing immediately. In a couple of months plenty of servers will support .NET 4.5.
The OAuth templates work for both v4.0 and v4.5 so you can publish them onto a server today itself :)
I'm currently working on an application that will likely be deployed amongst various organizations within my current workplace. I need to develop a testable and properly designed authentication framework so that for each implementation folks can choose to use either Windows Authentication, Forms Authentication, a home-grown Single-SignOn system OR OpenID.
So given ASP.NET MVC (and in particular I'm using the S#arp Architecture framework) how should I go about doing this?
Ideally it would be nice if folks can simply make changes to the web.config file in each case.
Thanks
ASP .NET MVC supports ASP .NET membership provider, making it easier for you to handle Windows/Forms Authentication without any hassle. As long as you specify the required information on the web.config. The default site comes with an example.
For other options of implementation, Kigg has an OpenID implementation which also includes the unit testing code.
I guess that after learning how those work you'll find a way to include your "home-grown Single-SignOn" authentication framework :P
Update:
In order to use the membership provider using your own users table, you must implement a custom provider. The configuration through the web.config will be available anyways, but you'll need to create a class which implements the MembershipProvider abstract class.
Here's a link to a video and some source code explaining how to achieve this.
I am moving a legacy winform app to the web and would like some advice on forms authentication. Am I correct in assuming that forms authentication is better than rolling up my own user authentication functionality?
It would be easy enough to roll my own since the this is what the winform application did and the table structure already supports it, but forms authentication looks like it would do a much better job securing the site and the user authentication info.
I'm an old programmer, but pretty young in web dev and I have learned over the years that using MS built in tools sometimes looks better than it works...forms authentication isn't one of those cases is it?
Thanks!
I'd say that Forms Authentication is a case where you're likely to experience no "buyers remorse". You can opt in to use some pretty nice features. The model is very flexible because it allows you to implement your own Membership Providers.
Using forms authentication doesn't means you don't get to use those tables. You will do the check for username/password, and tell asp.net that the user is authenticated. Asp.net will continue from there, ensuring further requests from that user are identified and authenticated (based on an authentication ticket).
Update 1: Later on asp.net included membership providers, with some controls for it. Even then you can still implement your own membership provider, which in really simple cases you can do by implementing only 1 or 2 of the methods. If you have several features, and they don't map well with what the membership provider supports, I would stick to a custom implementation.