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.
Related
I'm trying to understand the point of inheriting the Membership provider in a custom class and overriding it to implement your own custom provider.
What's the benefit of this when the Membership provider sucks in the first place!
I'm trying to figure out why people are inheriting from the provider when you can just roll your own. You're gonna have to create the logic anyway even if you override the membership provider classes. Plus if I'm gonna create my own provider I'm not necessarily going to want to model my method signatures or # of methods by this provider if I don't like it in the first place.
Yes, the built-in Membership provider sucks (I've had to re-write it myself, for use with large-scale sites where performance and scalability are concerns).
The advantage of using it is that it's easy, reasonably well documented, with lots of examples on the web.
The point of inheriting from the standard implementation is that makes it easy to just change the way a few things work. If you're going to re-write it from scratch, then I would skip the inheritance (which is what I've done).
You override the membership provider so that you can use the Membership API with it. This is useful for many purposes. For instance, if you're trying to integrate many third party web forums into your app, they require using the Membership API.
I fail to understand what people find so lacking in the membership API. Membership is not about having your users first and last names, or addresses or other information. It's strictly about validating login credentials, and providing role based security. That's it.
When you want to add other fields, you do so in your own tables, and make your membership ProviderUserKey a lookup value in your tables.
The main advantage is that the membership provider just works with all the "out of the box" asp.net features. Things like Forms Authentication, SiteMapProviders etc are designed to work well with the asp.net membership provider so often it's not so much the provider itself that is the key, it's the things that depend on the provider that make it worth while re-implementing.
Having said that, this doesn't mean that the membership provider will be a suitable fit for your situation, as you may not be using any of the components that are dependent on it, in which case, it doesn't make much sense to implement it and therefore you would be much better off writing your own membership model that does suit your needs.
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.
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.
Fairly new to ASP.NET's membership roles and forms authentication, it would seem that this would save more time and effort for my implementation.
But, I would also like to know if it comes in all goodness or does it carry any extra baggage (cons) in terms of:
Performance
Scalability
Thanks in advance for your replies.
I have never had a problem with performance or scalability with the default providers. Here are two tips that I've picked up along the way.
If you are using the providers and hashing passwords in a load-balanced setup. You will have to specify your machine key in the web.config
By default, users roles are not cached so every time you need to check a user role, you will make a round-trip to the DB. Using the cacheRolesInCookie="true" attribute in the tag in the web.config will cache them for you.
I've used the SQL Membership providers in ASP.Net in many large scale web applications and have never had any issue with it.
In our current application we've had to add extra fields and we expose these using an extra API.
Optimize ASP.NET Membership Stored Procedures for greater speed and scalability
Short answer: no real baggage in terms of performance and scalability. If anything, the real baggage is in terms of testability and portability (gobal static singletons are bad), but you can code around that.
It will probably work just fine, you can always switch provider or write your own later on.
I've written a provider that works as a layer between the ASP.NET authentication system and POCO classes together with a repository and nHibernate, that way I can let users login and get authenticated the ASP.NET MVC out-of-the-box-way, yet have the users and roles as any other model/view/controller in my system. Also by using IoC and interfaces I can use the exact same provider in different projects that handle users in different ways. Yay. Strange though that something like that didn't come out of the box.
If you use the default providers then it can be quite difficult to do things like search or filter users or do admin-type things, since you can't (easily) query the database directly. You have to go through the API, and it's quite limited. So, if you want to produce a lot of reports on users, be aware this is not easy to to efficiently.