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.
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.
What are the required steps to use SimpleMembership (ASP.NET MVC 4) with RavenDB (or other databases) instead of SQL Server?
I am used to override the MembershipProvider but how does it work with the new SimpleMembership?
I saw there is a SimpleMembershipProvider so I think I should override it, but I don't know if the methods are for storing data purpose only or if they should contain business/validation logic)...
What about configuration? I know the InitializeDatabaseConnection method is normally responsible for initializing the whole shebang, but I don't think I should call it if I don't use Entity Framework.
Unfortunately, I did not find a lot of resources about the new SimpleMembership except two links which have not been very useful:
http://igambin.blogspot.ca/2012/08/simplemembershipprovider-huh.html
http://blog.osbornm.com/archive/2010/07/21/using-simplemembership-with-asp.net-webpages.aspx
So here is what I found after looking at some of the the source code (MVC4).
http://aspnetwebstack.codeplex.com/SourceControl/changeset/view/553690ac9488#src%2fWebMatrix.WebData%2fExtendedMembershipProvider.cs
SimpleMembership is an implementation of the abstract class ExtendedMembershipProvider.
The code inside SimpleMembership is mostly SQL operations and some calls to the underlying (called "previous" in the documentation) MembershipProvider.
I don't think it is of any use (in my case) to override SimpleMembership as its implementation is mostly tied to SQL Server. Instead, for what I understand, I should implement ExtendedMembershipProvider. Then, by setting this implementation in the web.config file, the WebSecurity helper would bypass SimpleMembership (default implementation) and call my implementation of the ExtendedMembershipProvider.
I don't think I will do this any soon since it looks even more complicated than before (more methods to implement)... but still doable.
However, all this said, I'm a bit disappointed that we still have to work with the MembershipProvider which, IMHO, is far (a lot of static and internal stuff) from the whole dependency injection thing that we love so much with ASP.Net MVC/WebApi.
Edit 1
This question was aked before Jon Galloway wrote this tutorial :
http://weblogs.asp.net/jgalloway/archive/2012/08/29/simplemembership-membership-providers-universal-providers-and-the-new-asp-net-4-5-web-forms-and-asp-net-mvc-4-templates.aspx
But my answer stays valid as this (taken from Jon Galloway article) resumes it:
Note that SimpleMembership still requires some flavor of SQL Server -
it won't work with MySQL, NoSQL databases, etc. You can take a look at
the code in WebMatrix.WebData.dll using a tool like ILSpy if you'd
like to see why - there are places where SQL Server specific SQL
statements are being executed, especially when creating and
initializing tables. It seems like you might be able to work with
another database if you created the tables separately, but I haven't
tried it and it's not supported at this point.
Here's my implementation for mongodb. Maybe it can help
https://github.com/malibeg/MongodbSimpleMembershipProvider#readme
SimpleMembership is not really meant to be used with the old MembershipProviders as it doesn't fullfill all of the same contracts that are assumed of normal MembershipProviders. Its mostly designed for use via the WebSecurity helper.
This link might be helpful for more info: Web Pages Tutorial
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.