Think twice about using MembershipProvider (and SimpleMembership)
I’ve been talking about this topic since ASP.NET 2.0 was released in 2005 and to be honest this is sort of old news. I never put together a post on it, but since the new SimpleMembership is now released in ASP.NET 4.5 I figured now is time.
Brief History (as I have surmised) about the MembershipProvider.
Back in ~2003 Rob Howard from Microsoft had developed a sample application written in ASP.NET 1.1 showing how ASP.NET (WebForms) could be a viable framework for building common platforms such as web forums comparable to PHP-Nuke. Part of that effort was developing this notion of a “provider” programming model which was an abstract pluggable API for common aspects of the application architecture such as authentication. The idea is that a developer could plugin a custom provider to access arbitrary databases for the users’ usernames and passwords. The hosting application would simply code against this provider abstraction and the custom implementation would be used to contact the database, thus decoupling the two.
Sounds good, eh? So good that the ASP.NET team decided to incorporate the provider model for authentication (membership), roles, user profile, session and other aspects of the runtime into the ASP.NET 2.0 release in 2005. To capitalize on the provider model several new controls were added such as the CreateUserWizard, Login, ResetPassword and ChangePassword controls. These controls, given the provider model, could implement these features without knowing the details of the database being used.
On top of all of this, Microsoft even provided (no pun intended) concrete implementations of the various providers that used SQL Server to store the data (user credentials, roles, profile, etc). So to implement authentication in your application all you had to do was run their SQL script and drag-n-drop a Logon control onto the home page and voilà — security!
Wasn’t that easy? This was touted as the new way to do security in ASP.NET. In fact the membership provider started becoming synonymous with web application security. Also this new provider model was positioned as making security easy in ASP.NET. These last two points is where I have an issue…
What’s important in security?
It’s import to understand how security works in your application so that you can be confident (without a false sense of security) that it’s doing what you need and that you aren’t making mistakes in your application that somehow compromise this security.
By focusing on membership as what security is all about then the other important aspects of web application security are often overlooked. I wrote a bit about this already in how Membership is not the same as Forms Authentication.
Given that the majority of security in a web application is not in the realm of membership, what’s the provider model doing for us? Well, it’s just a database look-up. It’s an abstract API for managing users and their credentials. This is not to say that the storage of credentials isn’t important in web security — it is. I’ll come back to this later.
What’s wrong with the MembershipProvider?
The biggest problem with the membership provider is that the API is a very leaky abstraction. The MembershipProvider is an abstract base class for managing user credentials that has APIs such CreateUser, DeleteUser and ValidateUser (to authenticate credentials). It was originally designed for a forums application and has a total of 27 abstract methods that may or may not be pertinent to your application’s security needs. My favorite of these is GetNumberOfUsersOnline, which makes sense for a forums application (sort of) but otherwise is asinine.
Given the 27 abstract methods, a custom provider would of course be required to implement all of these. In many scenarios if the method isn’t pertinent then a NotImplementedException is the common implementation. The unfortunate part about this is now the application using the custom provider will need to know which methods are not implemented. Even some of the MembershipProvider-derived classes implemented by Microsoft throw NotImplementedException so you have to know which concrete provider you’re using. Herein begins the leaky abstraction.
Another one of those methods on the MembershipProvider is UnlockUser. This was designed into the API to allow an administrator to unlock an account if the provider detects that someone is trying to guess a user’s password. If the provider detects more than some number of guesses then it “locks” the account and prevents further logins. This is a decent feature, except there’s no automatic unlock so this security feature turns out to be a nice denial-of-service attack. Anyway, my complaint is that there’s no comparable LockUser API. What if an administrator decided the user was no longer allowed to login? A way around this would to be bypass the provider and update the database table that contains the flag directly (I suppose another approach would be to try to login as the user with a bad password over and over until their account gets locked). Anyway, this is an example of a missing feature where the API doesn’t meet a security requirement and the solution is to bypass the provider to achieve the goal. This adds to the leaky abstraction.
Given that the MembershipProvider is a base class, people are often misled into thinking they can derive from it if they need to augment the semantics (either for custom APIs or additional data stored with the user). One example is requiring more than username and password for authentication (such as a RSA secure ID for multi-factor authentication). To support this why not add a new ValidateUser that accepts three arguments instead of two? Technically it’s possible, but the built-in Login control isn’t designed for three parameters (let alone the CreateUserWizard). So you’d have to build your own controls for your custom parameters then then would have to downcast the provider base class to the custom provider class and manually invoke the custom ValidateUser method. All while pigeon-holing yourself into this provider model that doesn’t meet your needs (remember 27 abstract methods that may or may not be pertinent). Yet another leaky abstraction.
Another complaint (albeit a bit dated at this point) is that the SqlMembershipProvider is not using modern password storage techniques. This seems strange since in the same .NET 2.0 release in 2005 the Rfc2898DeriveBytes class was released which is the proper way to generate a password hash. My understanding is that the newer universal providers do use this and those are configured by default in the new project templates.
If you’re using MVC we don’t use the control model of WebForms. This means that much of the purported re-use of the provider model is lost due to the lack of Login, CreateUserWizard and other controls. The project templates so make up for some of this in MVC, though.
Lastly, Membership doesn’t follow SRP which forces provider implementers to violate DRY (which so highly regarded these days by modern developers). The logic of membership (mainly password management and account locking) should be decoupled from the rest (mainly the storage piece). Decoupling these two would allow for reuse of the good principals of account management while allowing alternative storage mechanisms without needing to re-implement the security parts. When I build my security systems, I build an account service that uses a user repository. This provides a nice separation of concerns.
For about a year or two after ASP.NET 2.0 was released on every new project I attempted to use membership with a good-faith effort, and on every project at some point our requirements exceeded what the membership API anticipated. We had to back out the code using the membership provider and build our own plumbing for storing user credentials.
What’s good about the MembershipProvider?
The good part about the membership provider isn’t the model per-se, but rather how the built-in implementations provide password management. When storing credentials, proper password hashing is crucial. This is the one useful thing from the provider model that you’d need to implement if you’re doing your own framework for storing credentials. Fortunately since the release of MVC 3 (and really Razor and WebMatrix) there is a Crypto class that provides modern APIs for password management and validation. So one more reason that the provider model is not needed.
Edit: I finally got around to posting about password management with the Crypto API. This illustrates how easy it is to manage passwords yourself. As I say below in one of the comments, I see this as the final nail in the membership provider coffin.
What about SimpleMembership?
There are some nice additions like the account reset token and the extensions to support OAuth/OpenID, but unfortunately I don’t think SimpleMembership improves on the situation. The SimpleMembership class ultimately derives from the MembershipProvider base class so it built upon the same house of cards. It seems obvious why it was designed this way — Microsoft wanted to provide some amount of backwards compatibility so that old code could still call into the new SimpleMembership implementation, but it’s still the same leaky abstraction issue.
Now the way they attempt to wean developers off of the leaky MembershipProvider API is they have introduced a new WebSecurity API that delegates to the SimpleMembership provider. This helps from a consumer perspective, but if you want your own database then you still have to implement a MembershipProvider and now we’re back to the leaky abstraction. Also the WebSecurity API continues to the blur the distinction between what the provider model is doing and what forms authentication is doing.
Also, another issue with SimpleMembership is that it has the same coupling of account management logic and persistence. SimpleMembership contains hard-coded SQL statements to build tables and performs selects, inserts, updates and deletes against their schema (and some of yours as well). The way it was coded, SimpleMembership is tied to a Microsoft database (SQL Server, SQL Azure, etc). It would have been nice if they could have decoupled the logic for supporting reset tokens and OAuth/OpenID account associations from the persistence of said data. If you want to store this data in another database you not only have to re-write the persistence code but you also have to re-write the same logic that’s in the SimpleMembership provider (so essentially the same SRP/DRY complaint above about the MembershipProvider). If you have to rewrite all of this logic anyway, then why pigeon-hole yourself into the leaky MembershipProvider abstraction?
It’s too bad since they had an opportunity to make a clean break.
Conclusion
If the membership provider API models exactly what you want and need in storing user credentials, then great — use it. But if you’re building a more complex application than your golf league website then chances are that you’ll need a bit more control over how this data is being maintained in the database.
The goal was to simplify but given the abstraction model and all the layers of Membership I find that people get confused and focus on the wrong details of security. I applaud Microsoft for the attempt… really. The membership provider model is an almost impossible API to design for everyone else’s security needs and that’s unfortunately why it so often falls short.
Edit: So as my rebuttal to the membership provider and since I wouldn’t use it in any real projects, I’ve always written my own account management code. Since I’ve done this time and time again, I finally decided to do it one last time and then open source it. So here’s my MembershipReboot open source library for account management. Bonus: It’s also claims aware.
Trackbacks
- APPLICATION SECURITY | Shanthu's Blog
- | Ryan's Happy Place
- gep13's Blog
- Announcing MembershipReboot | brockallen
- Web Dev 4 All | User authentication in ASP.Net
- SimpleMembership mit ASP.NET MVC4 und EF | SquadWuschel's Blog
- The good, the bad and the ugly of ASP.NET Identity | brockallen
- Be Lazy, Be Simple, SimpleMembershipProvider » Lock Me Down
- [RESOLVED]2013 Identity vs 2012 Membership systems | ASP Questions & Answers
- [RESOLVED]2013 Identity vs 2012 Membership systems | ASP Web Form Data Control
- [RESOLVED]Is using the built-in roles/membership a best practices method of handling logins for sties? | ASP Questions & Answers
- [RESOLVED]Looking for example of user admin features | ASP Questions & Answers
- [RESOLVED]2013 Identity vs 2012 Membership systems | ASP.NET MVC
- Improve Sitecore Membership provider performance 2-20 times | Brian Pedersen's Sitecore and .NET Blog
brockallen 
I would like to add one more issue, When user reset password by supplying Security question, it is visible in plain text format, we can change this in password format.
And another problem…doesn’t seem easy to migrate your existing data to the new SimpleMembership provider. See http://stackoverflow.com/questions/12236533/migrating-from-asp-net-membership-to-simplemembership-in-mvc4-rtm
Well, SimpleMembership manages passwords differently (and better) than the SqlMembershipProvider. But yes, they could have provided a migration tool.
Here’s one. http://pretzelsteelersfan.blogspot.com/2012/11/migrating-legacy-apps-to-new.html
have implemented membership providers in about 6 different web sites – all without any issue at all – they are a very *practical* solution to a common problem. I suspect many developers would say the same.
Agreed — we need a practical solution but the current implementation has many shortcomings as described above. You’re lucky to not have encountered them!
I often wonder why one would customize the Membership Provider Almost none of the methods are virtual which means I actually I have to come up with the code that does the same thing. For example, I need ValidateUser and am fine with the way it works. If I derive the MembershipProvider class, I end up having to come up with the same code for that method.
Also, if you truly need to implement all those methods, why not just write your own provider. What is the savings?
So what’s the alternate solution? Build it from scratch or use an alternate provider?
Great article! Thanks.
@The Senator – I think you are a little confused. Nearly *ALL* of the methods of MembershipProvider are virtual, abstract to be precise, but abstract methods are virtual methods that do not provide an implementation.
What you mean is that they do not provide a base implementation, which is largely what brock was referring to when he mentioned separating the storage from the logic. You can derive from SqlMembershipProvider and get those implementations if you like, and they’re all virtual.
@brockallen – I largely agree with your points, but not your conclusion. Ok, that’s not entirely true, I disagree with your title which should follow through to your conclusion, but your conclusion is different from what your title portends.
The fact of the matter is, if you don’t know what you’re doing when it comes to security, and particularly cryptography… then you SHOULD use a relatively secure default implementation like SqlMembership. All too many people get it wrong when they roll it themselves. (This speaks well of your point about separating the logic from the storage). It’s not perfect, but it’s better than fumbling through it yourself (unless you’re dedicated to learning the correct way to do it).
I agree wholeheartedly about MS blowing the chance to do it right. And I agree that SimpleMembership is a terrible bastard step-child trying to appease too many people (those that want legacy compatibility and those that want customizability).
Unfortunately, all too many people completely misunderstand the point of Membership, and I blame Microsoft for not making this clear enough. The number of questions on Stack Overflow about how to add things like First and Last Name, mailing addresses, etc… to the membership system is a testament to that.
And it never fails, there’s always 20 or 30 people to jump in and say “Write custom membership provider” rather than addressing the real problem (likely because they are confused as well). More often than not, writing a custom membership provider is the wrong answer.
Maybe Microsoft misnamed it. Maybe they should have called it a CredentialProvider, which would have been far more accurate, but I suppose might have been confusing when compared to other kinds of credentials in the framework. Membership implies a whole lot of things, which the Membership system is not designed for.
I find that most people who write custom membership providers don’t need to. They use lame excuses like “SqlMembership is too bloated, and does more than I need”. That’s largely a stupid argument, because you can ignore any of the things you don’t need. Others argue that the tables are too complex. Well, the idea is that you aren’t supposed to use the tables, you’re supposed to use the API.
By the way, regarding your comments about LockUser, I think you are looking at it the wrong way. There is no need for a LockUser because the account should only ever be locked if the password tries has been violated. If you want to prevent a user from logging in, you can just set the IsApproved flag to false. Or you could set the IsLockedOut flag to false as well. You don’t need to bypass anything, because this can be done through calling GetUser, updating the property, then calling UpdateUser to save it.
I also disagree about the uselessness of the number of users online feature. Setting aside the fact that it’s at best a guesstimate, you can use it in administrative pages to see how things are going. So it’s not entirely useless from a non-forum perspective.
Do I have a love/hate relationship with Membership? Absolutely, but I feel a lot better about using ASP.NET sites if they appear to be using membership than I would otherwise. It’s significantly better than having any old developer roll their own. So the way I see it, if you know why you shouldn’t legitimately use it, you’re probably skilled enough to roll your own correctly. And if your first though is to roll your own provider, then stick to the default provider.
Sorry for the long winded response, but your article had a lot to address ;)
@Erik — Thanks for the thoughtful comment. I think you and I agree on most everything.
I concede there are workarounds to many of the complaints I raise, but it’ll an illustration of the fact that they didn’t design this API very well, added it to the framework without much scrutiny and now have to support and promote it since it’s part of the framework.
We also agree on the point that most of this debacle is due to Microsoft wanting to make it easy for people by providing an abstraction and then failing to educate people on the topics that need education. Abstractions don’t alleviate the need to understand how lower level things work. Abstractions simply make it easier to work with them.
I think you’re right that far too often people receive suggestions to “just create a custom provider” and that’s not really the right answer (because then they do have to do their own password management for one). This is typically indicative of the lack of understand of the layers involved.
I guess the point of the post is to try to educate people on where the provider really fits into the security story, what the failings are and to simply let them know they don’t have to use it. And if they do need to build their own, hopefully I hinted enough in here to make them cognizant that the crypto is the tricky part and that they need to learn how to do it right. I’ve been meaning to do another post on this, so you’ve galvanized me :)
Ok Erik — here’s the final nail on the membership provider coffin :)
Hallo Brock, I’m really new to OOP and ASP.NET so as I start I thought Membership could do the job, most of all to keep a sort of compatibility with eventual third party snippets, but soon after I discovered it simply didn’t fit with my requirements (hierarchical roles, tasks, paths tied to users and roles and so on…).
So now I need to understand how to create my authentication, membership and role providers and how to hook in the application events lifecycle. In particular I think is better to write them from scratch rather than derive from the base providers and override/add methods).
You have far more experience on the subject so I just would like to ask:
– Is ok to remove in web.config the defatul authentication module and plug in my module?
– I will also remove urlauthorization module since I will keep this functionality (users > roles > paths) in the db to make it dynamic. And I will plug my authorization module
– How should I build my new providers? Should I keep the provider model or just create “standard” shared classes? If it’s easier to keep the provider model where should I start from (deriving from? where and how to insert it in web.config) can you point me to some easy resource?
– It seems that the source codes for the default HttpModules are not available, just reflection of them or there are complete and detailed sources for at least authorization and authentication modules?
– Last but maybe most important… what should be “produced” from my rewritten modules? An User class attached to HttpContext.Current? Only this?
Sorry for bugging I just need a little fire to start in the right direction but I cannot seem to find really in-depth and easy to grasp documentations on this procedure of writing auth modules and providers from scratch.
– It sounds like you might want to keep the default authentication module (Forms) since that’s simply letting you know who the user is (it’s cookie based). It does a good job, so no need to rewrite it. What you don’t need/want is the provider piece, which is just the DB lookup to validate credentials.
– UrlAutrhoization still might be useful for coarse-grained checks. You can still write your own to augment that the UrlAuthroization is doing. But if it does you no good, then sure, remove it.
– Your “providers” are just your backend business logic to validate credentials and load profile information for your users. You don’t need to follow the MSFT provider pattern — just design your APIs for your scenario.
– Correct — I use reflector to understand the code in the default http modules.
– This last one depends. The simple approach is to just use as much built-in functionality as possible — use FormsAuthentication and GenericPrincipal/GenericIdentity as need be. But if those really don’t have what you want you can build your own. I guess it all depends on the app and the requirements. Not to over complicate things, there’s also the concept of claims which is a more modern way to model user identity.
I have a sample at https://github.com/brockallen/BrockAllen.MembershipReboot that is meant to show how to do many of these things without the built-in providers as well as supporting claims.
Thank you Brock you really helped me a lot both in asp.net forums and here.
I think I will have to rewrite authentication part as well (I already have the analysis of the user / roles cookies I need, I have all the tables already for authentication and authorization and I also disabled session state). In this process I will for sure use your suggestions on https://brockallen.com/2012/10/19/password-management-made-easy-in-asp-net-with-the-crypto-api/ to store passwords.
FormsAuthentication will be replaced by my business classes but I can still leverage the GenericPrincipal/GenericIdentity context.User stuff in them right?
I’m asking just because I’m concerned if this is used elsewhere in the built-in asp.net modules or stuff (like the cache module for example).
About claims this could be a “second step” even if I understand it’s the future of authentication and user data persistance but for now I think I will have to stop at this stage, since I really am totally new to OOP and ASP.NET as I said, I just have an old classic asp framework built on my own and now willing to migrate/improve it and make it multiapp for level 4 SaaS management.
I’m going to take a look at your example. Really many thanks again.
Manight,
I would question whether or not you actually *need* everything you are talking about. First, your lack of experience would tell me that you probably don’t have a lot of security experience either. Security is one of those things that “seems” simple, and the concepts basically are. However, the implementation of it is where it’s not simple.
One should always strive to implement the least complexity possible when it comes to security, and one should strive to re-use well-debugged and understood methods. It’s really easy to design a really complex and powerful security system in theory, but in the actual code you end up with vulnerable, insecure, conflicting scenarios because most people really don’t think through the full ramifications of what they’ve designed.
A simple example. Let’s say you have “role inheritance” (not entirely sure what your requirements are on that, but there’s at least a dozen different things that could fit that category). What happens if you have both an allow and a deny setting (one is inherited)? You can end up with really buggy and weird results.
All too often, people design security they will never need or use. They create flexible systems, that allow complex micro-managing.. and then nobody uses it because it’s too complicated, and it quickly becomes a nightmare to maintain. Windows ACL’s are like that in many ways.
Membership and Role providers provide a simple, easy to use membership and role system that works for the vast majority of people. I would seriously question whether your design really *needs* the complexity you are suggesting. In my experience, for each layer of complexity you add, you geometrically increase the level of due diligence you must give it to ensure it’s security and robustness. Keep it simple, and you won’t pull so many hairs out of your head.
Hallo Erik, thanks for your reply, every hint is always welcome!
I have zero experience with asp.net (and oop) that’s true, but I’ve been coding with classic asp for around 15 years and developed a solid framework from scratch with that tech.
In this framework I already implemented all the things that now I want to port with the migration (role hierarchies, pages/roles/users/tasks permission system and so on..).
I worked with all kind of tree structures from nested sets to materialized paths to adjacency models.
It’s true that I’m not very well “documented” with encryption/decryption stuff but it seems the libraries provided with asp.net do the job well.
For the other security concerns, even if not on .net tech I had some hands-on experience in those years of web development. In my framework I used a token based security system with token reissued on each page request, but now on asp.net since there are really nice cookie encryption method I’m sticking to just a little modified auth token (I want to include in it the amount of sliding expiration to make it customizable per user, and other very little things).
So just to make it short where I’m lacking is in the in-depth knowledge of asp.net framework and the nuances of experienced oop coders of course.
In those months of studying and practicing I think I have now enough information to go down this road, I just need a bit of help to avoid common pitfalls, like for example knowing if the other default httpmodules access somehow the User class and such things.
Then maybe my solution will not be elegant in an “oop way” (but I’ll try) but I’m confident I can spot most security pitfalls from an analytic standpoint.
I’ll try to keep it simple but I’m doing a porting of a well tested (in those years) framework wich is already a bit complex and want to fix some analysis issues discovered during those years of experience and add functionalities (like multi app support) so I will need to complicate things a bit I guess :)
brock I think you were right about the default authentication module… it has nothing to do with password validation or roles it just checks the cookie and the slide time is already in it, so I think I’ll follow your suggestion and leave it in place! Thanks again
So what should we use?
@drewid — build it yourself. I have a sample here: https://github.com/brockallen/BrockAllen.MembershipReboot
I downloaded the sample but don’t see a complete picture as there is no database (are you running against the same schema as MS membership?) and no sample code that actually shows how to login, register, change password, etc.
Did you just build the solution for the library or the solution for the sample app? The solution in the samples directory is a full sample that should auto-create the database. And MembershipReboot does not use the same schema as the MSFT providers (this is a feature).
I am of the same opinion. I am going to create a project in codeplex soon which will have a better implementation (most of the ideas borrowed from the old provider model). This will include for support for claims (without the need for STS etc.) in addition to roles.
I’ve already created one: https://github.com/brockallen/BrockAllen.MembershipReboot. Feel free to contribute :)
Looks first rate – really looking forward to scratching the surface.
Where can we read up on claims?
http://msdn.microsoft.com/en-us/library/ee748475.aspx
I will take a look.
Hi brockallen. Nice post. But I would like to know if you have a documentation for your code. I have downloaded it. But a little complex to understand. If I can get a documentation I believe I would have a better understanding.
Do you mean the membership reboot project? The only docs I have is the sample app that’s in github.
Yea I mean the Membership Reboot project. I have downloaded it and I am currently studying it. it has a lot of source files. So I wud be happy if you have a doc. to simplify it.
Well, given my time constraints the sample MVC app will have to do for now. Sorry.
I had to laugh about this a little bit. First, GetNumberOfUsersOnline can be used for MANY things other than a forum. For example, you could use it for an ecommerce application or your website if you want to know if you have users on your site.
The providers can ALL be extended! So if you need a feature, ADD IT! Don’t complain that it doesn’t exist – just extend the provider and add your feature!
Of course it can mean anything, but I think you’re missing the point. My issue is that it doesn’t really have anything to do with validating user credentials. Also, it doesn’t help that many of the built-in providers don’t implement it and throw, so this adds to the leaky abstraction problem.
Sara, you’ve largely missed the point. The purpose of Membership is to have a pluggable architecture. If you extend it, then it’s no longer pluggable since you’re depending on functionality that won’t exist in other providers. If you don’t need a pluggable architecture, then what’s the point of using one that’s pluggable?
My biggest beef with Membership is the same as Brock’s, it’s a leaky abstraction and most of the providers out there don’t implement the full API (including SimpleMembership and other providers from MS). It really is poorly implemented, poorly designed, and poorly conceptualized. It doesn’t follow any of the SOLID principles, and it creates a lot of confusion.
Great post. I too use an IAccountService with a concrete implementation that calls into a UserRepository. I’ve finally read something that backs up what I’ve been doing. I’m currently building a system whereby a company can have an account and each account can have multiple users so authentication requires an AccountName, Username and Password (3 parts as described in your text)
Hi Brock,
Just found your MembershipReboot project. I’ve been researching membership for about a week now, and my feeling is things are pretty confused and messy. I’m planning on using Claims in my application so go the notion that it’d make sense to store claims instead of Roles. Looks like that’s and option with MembershipReboot.
Interestingly, the old Application Client Services in .Net 3.5 has many of the things I want to use for my current project. Funny thing is, the fact that it targets .Net 3.5, and uses the old membership providers etc, makes me not want to use it… I’ve been following Dominick Baier, and have watched all his Pluralsight videos. He does a great job of covering claims, but I haven’t found much of anything on Pluralsight regarding Membership other than some stuff targeted at SimpleMembership for MVC4. I’m doing SOA, and would like to have my membership available over a WCF service… I have created my own entirely, but then started to feel like this is something that I should depend on someone more experienced for… Honestly for my application, which will have about 20 users, what I have would work, but I’m finding it very hard to be pragmatic about all this…. I don’t just want it to work, I want it to be correctly architected something I don’t have to unit test ;)
Yep, claims are the way to go. And yes, MR supports storing claims with the user account. I think MR is a good choice, even if your app only has 20 users. Anyway, if you have questions about it, feel free to post on the github issues page.
Hi Brock,
I’ve been looking at the MembershipReboot library and have a question about the implementation, specifically the boundary between the UserAccountService and the ClaimsBasedAuthenticationService – it’s not an ‘issue’ as such, hence posting here, rather than on github.
In the Login Controller of the Single Tenant Web App you call Authenticate on the the UserAccountService and then SignIn on the the ClaimsBasedAuthenticationService and I’m not certain what the conceptual difference is here. The ClaimsBasedAuthenticationService has a concrete dependency on the UserAccountService and in both calls you go to the DB in order to hydrate the UserAccount object (via the UserAccountService) which is then used to authenticate in the first case (the call to Authenticate on the UserAccountService) and then load the claims for the account and write the FedAuth cookie in the latter (the call to Sign in on the ClaimsBasedAuthenticationService).
I don’t understand why these actions are separated out (i.e. why there is an Authenticate method and a SignIn method) and why you wouldn’t Authenticate a user and persist their details into the FedAuth cookie in one go. Could you illuminate a little?
Thanks,
Steve
It’s possible that you’d need to authenticate a user that’s not in a browser-based application.
Thanks for taking the time to respond. I’m afraid my focussing on the specific example may have made my question less clear. However, thinking about this some more, I think my problem comes down to a language issue – specifically the name of the ‘Authenticate’ method on the UserAccountService.
If the client application calls Authenticate and then checks if the current user is authenticated (using ClaimsPrincipal.Current.Identity.IsAuthenticated) that would return false, which to me is counter-intuitive.
Client website: “Authenticate this user”
Auth mechanism: “Yep, that’s all OK”
Client website: “Is this person authenticated?”
Auth mechanism: “Nope”
In the MS template application first step of checking credentials is called called ‘ValidateUser’ and nothing is called ‘Authenticate’ (which is also weird as we’re definitely authenticating people here). I guess I like the MS project layout, whereby the MVC controller calls a ‘Login’ method and all the Authentication work is dealt with elsewhere. Of course that would have made your sample app more complex, so I can see why you haven’t done it.
Hmmm, I’ve rambled a bit, but cleared up my own thinking :) Thanks again for the response (and for the code, I’ll be using it in my own applications).
Steve
Since you are storing the password in a secure manner, how important is password strength? Is it no longer an issue? Or should we still require at least 8 or 12 characters, numbers, no repeating characters, etc. etc.?
It’s still important since it helps thwart brute force attacks.
Thank you. Another deficiency is the lack of good out-of-the-box integration between OpenAuth/OpenID and the SimpleMembership features in the Universal Providers. For a concrete example that reflects your observations, custom code is required to persist email addresses of OpenAuth/OpenID users.
@brockallen – hope it is not too late to post on this forum. I was walking through the code for IdentityServer V2 and you one of the major contributors. I see that you have used Membership provider in there. If so, is that contradicting from what your blog title says? I am confused.
Well, there is some history and a certain amount of practicability in IdentityServer using and supporting the old Membership provider. When IdentityServer was initially developed, MembershipReboot didn’t exist and so most people were familiar with the Membership programming model and many people had adopted it. But, now, we do have a sample of using MembershipReboot with IdentityServer and IdentityServer v3 (the upcoming version) will not provide support for the old Membership provider API.
That was so quick. Thanks. When is this V3 expected and any hints on what would replace the Membership provider API?
Well, to replace Membership I suggest MembershipReboot: https://github.com/brockallen/BrockAllen.MembershipReboot/
IdentityServer v3 is soon :)
I have to agree with this article. It seems most of those disagreeing simply don’t understand the benefits of DRY and SRP. Here’s one more con to the MembershipProvider model: Dependency Injection is impossible. The only way to get dependencies into your MembershipProvider is to use a IOC solution like Ninject or Unity with Setter Injection or use the Service Locator anti-pattern. Both of these methods create a dependency on the IOC solution, which makes your MembershipProvider less portable.
Hello, I am doing some background reading on Identity and related issues deciding how best to fold that into a (more or less) green fields app; sort of. I want to replace things like data store and so forth because I’ve got those things accounted for in my domain model (first). How necessary is MembershipProvider, really? And given your critique, what are you suggestions what else to do?
https://brockallen.com/category/membershipreboot/