What do large websites built in .NET use for their login components?
I will be implementing the login and membership features of a large .NET web application. As I see it, there are 4 options:
Leverage the default Microsoft Membership Provider
Build a custom Membership Provider
Use a different 3rd Party Component
Build an entirely custom login/authentication framework
I am trying to optimize for reliability, so I would like to know if sites like MySpace or PlentyOfFish have already established a best practice in this area. The real motivation for this question is I want to validate that the MS Membership Provider strategy will scale well.
I know StackOverflow uses OpenID, but I don't think that would be a good solution for what I am working on as a lot of my prospective users will be non-technical. Feel free to pitch why OpenID should be considered if you believe strongly in it.
Always rely as much as possible on platform-provided tools for security tasks such as authentication.
In this case, that likely means inheriting from one of the stock MembershipProviders. That will let you re-use all the existing code for the provider, plus any tweaks you need to make it work with your existing system. It's possible you can find a 3rd party component that works well for you that already does this.
Related
Haven't done security in ASP.NET before. Need to secure an MVC site - simple username/password access for admin access to the site's logs and admin areas, not for general users.
Looked into Identity/OWIN, and it is, as of this writing, half-baked. There are multiple ways to do things, the docs are few or non-existent, and blogs dicuss deprecated or alpha versions. The samples don't correspond to anything in the docs or blogs. In short, it's a mess.
Security is hard, so I want to use something that was written by an expert, works and is tried-and-tested. Must be from Microsoft, not some third-party stuff.
So what security API came before Identity/OWIN, which works well and hasn't been compromised? They've released many, so I don't know which to use?
Forms Authentication with custom Membership and Role Providers were used for years and still can be used. The SimpleMembership is something that tries to simplify the original provider model but sacrifices too much, in my opinion plus it us still not that simple.
There are thousands of tutorials on Forms Authentication and you should be able to start immediately. The Membership/Role Provider model is also extremely well documented.
In terms of correspondence
Membership/Role Providers correspond to the Identity api
Forms Authentication corresponds to the owin security api
The predecessor to Identity/OWIN was SimpleMembership.
However, according to my question "What is MVC4 security all about?", SimpleMembership is an oxymoron.
I have a question. I am looking at the newly implemented Simple Membership Provider and it suits my needs out of the box. I am however a little concerned about this provider as I am looking at creating a custom web application for myself and would like to know the security pros and cons of using it and if there is any best practices to go about building a secure web application. Is simple membership secure ? I am a noob when it comes to security.
I recommend not writing your own authentication and session management routines. Security is difficult and any flaws in your design or code could lead to exposure or breaches.
We have used Simple Membership in several web portals that handle PHI (protected health information). Our clients routinely audit our development methods and none so far have considered this a risk. Had we developed our own, they would raise a red flag.
You probably can get further by creating a library class of helper functions to add the features you feel are missing from existing providers, or subclass an existing provider (I don't think they are sealed/final).
In any case, your first step would be to draw up a list of features you want, check to see if an existing provider already does that (for example if you want an XML file provider, one exists on CodePlex), and if none do, either extend or write your own. If you write your own, you would want to make sure that there is another layer of security, like being on an intranet, or local access only or some other layer of defense.
I know there's tons of questions about .NET based CMS out there, but I have some specifics things I'm looking for.
1) Be able to leverage our application's existing authentication (We have our own implementation of of System.Web.Security.MembershipProvider as well as MembershipUser)
2) Be able to restrict who can view certain pages/segments based on our custom roles, in addition to restrictions on who can edit them.
Maybe most of them support this, but I haven't had much luck finding which ones specifically satisfy these requirements.
(Being lightweight is also a plus, I've read about Orchard and N2)
I don't know how much this will help you but here goes. We did a search last year for .NET content management systems and I wasn't super thrilled. There are a ton of commercial systems that are really expensive and appear to be crap.
I checked out N2 first. It seemed really clean, but it was way too barebones for our purposes. We would have had to do a ton of custom development to meet our needs. It's really a CMS framework instead of a CMS product.
Umbraco was the other system we took a serious look at. It has a lot more features built in and it's a fairly nice system as long as you don't mind a little XSLT. It does use the standard membership provider framework, so that's in your favor. I don't really know whether the roles will do what you want though. But since it's free you can play with it to see if it meets your needs.
As for Orchard, I don't know much about it. It wasn't around when we were looking, but it seems interesting. I couldn't tell in a reasonable amount of time how it handles membership and roles on the back end. It does seem like it's geared towards smaller sites, so it might be a little limiting in that respect.
We've been using Telerik's Sitefinity product with custom forms authentication. You can use forms authentication out of the box or you can customise it. It does make use of the provider model too.
More information on custom authentication can be found here.
I would suggest looking into AxCMS (at AxCMS.net). It is complete, pluggable and has extensive documentation. Specific documentation about their implementation of Membership and Security is available at : http://help.axcms.net/en_help_concepts_security.AxCMS
Microsoft's Scott Gu recommends it here at http://weblogs.asp.net/scottgu/archive/2006/02/02/437220.aspx
EPiServer is a commercial ASP.NET based CMS. It is essentially a set of .NET assemblies that you reference and build into your ASP.NET application to turn it into a first class CMS.
It makes use of standard ASP.NET features like the provider model so you can swap bits out.
I just discovered ASP.net uses its own profile system to register users and there seems to be a lot of features available as bonus with it (such as secure authentication). However it seems rather specific to have such a feature for a general purpose development environment and things which work in the background the way the profiles system does without me really knowing how (like where the user data is stored) kind of scares me.
Is it worth developing a website which requires user authentication using the asp.net profile system or would it be better to develop my own using SQL databases and such? I'm not going to avoid using SQL anyway, even if I use profiles I'll use the profiles unique ID to identify user data in the SQL table so in that sense I'm not going to avoid using SQL for user information at all.
My favorite thing about profiles is that you can create custom permissions in Web.config files using them () and avoid having to type in the same code to the top of all your aspx source files to do the authentication check.
The other thing I kind of like about it is that security is built in with secure authentication cookies, so I wouldn't have to deal with them myself.
But it doesn't seem like that big of a deal really. I'm just confused as to where profiles stand as far as ASP.Net development goes and what they're designed to accomplish.
The Profile/Membership and Role provider API is very intertwined, and specifies things very narrowly. The benefit is that there is little you have to do to get a lot of functionality working. The disadvantage is when what you need doesn't match what is provided. Nevertheless, there are many potential gotcha's that the API takes care of for you that it really does make sense to use it, at least for authentication.
My needs did not match what the API provided, and I really only needed the Membership portion. The problem is that I had a piece where I needed to use the same authentication and authorization across a web application and a desktop application. My needs are pretty unique, but it's designed for a classroom setting.
Getting the membership to work for my needs wasn't that difficult. I just had to implement the Membership API. There are several features I just didn't need with the Membership API like self-registration, etc. Of course this did present me with a challenge for role management. Typically, as long as your user object implements IPrinciple it can be used directly--but there are serialization issues with the development web server Visual Studio packages if your user class is not defined in the same assembly. Those problems deal with serialization, and your choices include putting the object in the GAC or handle cross-appdomain serialization yourself with objects that are in the GAC like GenericPrincipal and GenericIdentity. That latter option is what I had to do.
Bottom line is that if you don't mind letting the API do all the management for you, than it will work just fine. It is a bit of smart engineering work, and attempts to force you down a route with decent security practices. I've worked with a number of different authentication/authorization APIs (most were not CLR based), and the API does feel a bit constraining. However, if you want to avoid pitfalls with session/state/cache management you really need to use the API and plug in your own providers as necessary.
With your database, if you need to link a user with any database element you'll be storing the user's login id (Context.User.Identity.Name).
You seem to mix the Profile/Membership/Role provider API. But to answer your question: why not use it? I would use it unless there is a real constraint that makes it unusable...
I am currently converting a very old, but working classic ASP site to ASP.Net.
It has a completely custom written user management system. Whilst it works fine, it really needs a refresh as I want it to be more flexible for some future projects in the works.
When I asked someone about this, they said "You need to use the Microsoft Provider" and gave a lecture on how Microsoft release all these things for free and how good they are and should be re used as much as possible.
I have done quite a bit of research on it (mainly looking at the videos on http://asp.net/learn ) and am very impressed by some of the features as there appears to be drag and drop components for items that would take me ages to write.
However, the current membership database is complicated to explain, it is a completely custom written database that has many internal relations... It is not really "compatible" with the default Microsoft Provider.
I have taken a look at How Do I: Create a Custom Membership Provider?, but I feel a little out of my comfort zone and worried it will either be slow, introduce a security hole or simply won't work.
At the end of the day, the Microsoft Membership Provider should work for me - the only customisations I really need is the login to use the username/password field in my database and the create user script which has a lot of custom code to several third party systems (needing to provision services etc.).
I was just wondering, what would you do if faced with a similar situation?
Use the Microsoft Membership Provider and somehow get it to work for you (although I would like suggestions)
Use the Microsoft Membership Provider but use custom provider that is customised around your code.
Use your own completely customised solution?
That video does complicate things :) If you're going to implement a custom provider then reflector over the existing one is a good place to start :)
As a quick and dirty option you could, of course, hack the stored procedures that the SQL Membership provider uses but the custom code to provision services is probably stretching that.
If you think about it the remote provisioning of services doesn't really belong in a membership provider, it's not really a membership function - all membership does is provide usernames and passwords and authentication around them. My own feeling is that you should move the provisioning of services out of there, and perform it on the ASP.NET site after a user has been created - even if that's just calling a stored procedure once the membership provider has done its thing. If you do this you may find that the SQL membership provider will do everything you need it to (probably with the Roles & profile providers too), and thus you have way less code to write!
I've been in similar situations in the past. In both cases we created custom implementations of the providers (MembershipProvider, RoleProvider, ProfileProvider) around the existing mechanism.
In both cases we only used the provider implementations for read-only access, e.g. to give us the easy validation gubbins in web.config and suchlike. The user administration code was left well alone as it worked just fine.
If the existing provider works (has the right fields for your data), use that to start. You can VERY easily replace that with a customer provider later (just a single config value change).
Beware there isn't an "out of the box" ASP.NET management interface for that, you'll need to roll your own or use a third party one.
Use my specialized MembershipProvider to work against my own database tables.