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?
Yes, these two components would play together nicely. In fact, one is built upon the other.
The more important question is, do you need both for your particular scenario? Look at what the MembershipProvider functionality gives you out of the box. What is it that the EntLib Security Block adds to this that is necessary for your application?
Related
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'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'm implementing a Custom RoleProvider in the .NET Membership-framework. The existing functionally needs a little tweaking, so I want to implemenet my own Public Functions, to invoke around the static Roles-class.
Instead of Object -> Roles -> RolesProvider
I would go Object -> RolesProvider
Would this be considered bad practice? The only alternative with the current databasescheme is to ommit the use of RoleProvider totally, and implement my own custom system for authorization.
Edit: To clarify, I have already implemented a custom MembershipProvider, so the desire to keep working in the Membership-framework is pretty high.
Any time you circumvent part of a framework or customize it in a way that was not intended it could be considered bad practice. It is the intention of the ASP.NET membership provider framework to facilitate access to the current provider through the Roles class.
The danger of 'bending' the framework to suit your needs instead of extending it as intended is this: there may be other areas in the .net framework, configuration or tools around the role membership functionality that make this assumption, and they may no longer make sense after your changes and cause confusion for others involved in your project. The ASP.NET Website Administration Tool is one example of a tool that makes this assumption. If someone were to use this tool after your changes, your role memberships and site could be potentially corrupted as a result.
If you decide to take this approach you should carefully consider what functionality you are adding and ultimately ask yourself it is really necessary. If it is, you may be better off implementing something completely custom instead to avoid confusion.
I've got an upcoming project that is going to be dealing with 70,000+ users (education). I was wondering if the ASP.NET SqlMembership Provider has been used at such large capacities? Assuming the hardware is there, is there anything special that needs to be done to make it work smoothly? We're doing all the obvious things like separating boxes for databases and applications, but is there anything code wise that I need to watch out for?
I know one site that, owner of this site wrote a brilliant article about asp.net performance(http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx)
On this article there is one subject that author describes a patch about profile provider for higher performance. Please read that section.
Inbuilt SqlMembershipProvider is very reliable and workable. They tightly integrate with FormsAuthentication and Login Controls. So authentication is reliable and it is also quick to implement.
Only problem I see is the complexity of the Database table structure, they are quite tidy and not so straight at first. So you can basically write your own MembershipProvider that will talk to your own users table with more simplistic design and implementation. Also Managing Members on admin is also painful due to table design but in a way it is fairly possible to do so. For these reasons we wrote our own MembershipProvider based on Sql. It's working amazingly and we've had good experience of the same.
If you have a small website or project
you can straight go on with inbuilt
SqlMembershipProvider but for a large
project like yours I'd recommend
writing your own MembershipProvider.
I have been building web sites with ASP.NET for a while now. At first I avoided learning the intricacies of the ASP.NET Provider Model. Instead I used the canned providers where necessary, and leaned heavily on Dependency Injection frameworks for all my other needs.
Recently however, I have been writing pluggable components for ASP.NET and of course writing lots of custom provider based solutions in order to make that happen. It has become quickly apparent to me however, that a lot of initialization code is being duplicated, which is a bad thing.
So...
Are there any best practices that have emerged on how to avoid the configuration spaghetti code?
Have you built, or have any examples (base/helper classes, custom attributes, reflection) to share of abstracting the basic initialization code out so building custom providers is easier?
NOTE:
Please do not try and send me to the Provider Toolkit site. I have already exhausted that resource, which is why I am turning to the SO Community :)
I just did a rough implementation of rather basic implementation of the membership and role providers, and I don't have any code duplication at all!
I have divided everything into three projects (plus tests):
Application - asp.net mvc app. models, controllers etc.
Infrastructure - IoC and Interfaces
Infrastructure.Web - Providers
The model for User and Role implement interfaces from Infrastructure and those classes get registered to the IoC on application startup. The providers then asks the IoC to resolve the classes and does it's thing. This way I can add things to the model and user interface yet using the same providers. The one problem I've noticed, is that the web being launched by the "ASP.NET Configuration"-button can't use the providers, as the setup is being done in Application_Start and the "ASP.NET Configuration" is another web. I don't see this as a problem though.