I have been tasked with implementing point 4 in this article: http://support.microsoft.com/kb/900111
This involves using the Membership provider to add a comment to users server side records when they log in and out, and then confirming that when a cookie is used to authenticate, that the user hasn't logged out. This makes perfect sense to me. Where this starts to fall apart is that we do not currently use a membership provider, and so it seems like I face reimplementing all our authentication code to use a membership provider. We currently check authentication in a controller, and make a call to FormsAuthentication.SetAuthCookie() once we know the user exists. It would be a lot of work to force a membership provider in.
Is all this work really neccesary. Can I roll my own key value store of cookie values to logged in users and just make sure I clear this when a user hits the logout button. If this seems unsafe is there a way of implementing a minimal Membership provider in order to make these checks without handing off all authentication code to it?
I guess my main problem here is that we decided a long time ago that the membership provider model doesnt fit with the model we use for locking and unlocking accounts, and chose not to use it. Now we find that the MS recommendations specifically mention a membership provider, and as this is security I need to be sure that not using it as they recommend isn't going to cause troubles.
Can I roll my own key value store of
cookie values to logged in users and
just make sure I clear this when a
user hits the logout button.
Yes, you can do this. The Membership Provider keeps a small set of data about the user (username, email, password, last login, lost password question, lost password answer, etc).
If you don't want to retro fit a membership provider I would take the approach you mentioned. Whether the information is written to the comment field of the aspnet_Users table or a bit field in your own table, it shouldn't make any difference.
You also might want to consider putting an interface your Membership/Authentication code. Then you could swap your current code to a Membership Provider implementation when it's more convenient.
I've found the MembershipProvider to be very helpful. It allows me as a developer to use the SQLMembershipProvider against a local database of users, and then when I move it to production, to simply use an ActiveDirectoryMembershipProvider and I don't have to change a line of code (except in my web.config file).
Using their CustomMembershipProvider, you can overload any of the authentication methods and do whatever other checks you want inside of those methods.
If you decide to jump to the MembershipProvider scheme, I don't think you'll regret it. It may be painful in the short term, but in the long run, I think you'll see it paid off. Since you've already got a lot of your authentication code written in your controller, perhaps it won't be that hard to meld it into the way MembershipProvider uses it?
...is there a way of implementing a minimal Membership provider in order to make these checks without handing off all authentication code to it?
MP is one of those times when its best to let it do what it does best. If you try to use just part of it here and part of it there, while possible, will cause some headaches down the road. It knows what it is supposed to do and circumventing it, while possible, will require extra work that may turn out to be unnecessary.
Related
In a generic asp.net website with Membership, Roles and hashed passwords enabled, I would like to provide the administrators with impersonation so that they may browse the website as that user would. The website should function as if that user is logged on and then be able to revert to their own login.
What is the best approach to achieve this?
An example use-case: A website with two types of users: 'Buyer' and 'Admin'.
The website provides a 'Purchase' button to buy something specifically provided to the user by the admins. i.e only that buyer can use the purchase button and make a payment.
User has trouble so a support admin can 'impersonate' the user's login and purchase on their behalf or 'see' the trouble they are facing.
Without impersonation, the only way is to allow this in code and that negates the purpose of 'seeing the user's issue'. Not even if I was not using hashed passwords and had used FormsAuthentication.SignOut() and manually logged in the admin as the user.
I hope i am making sense above.
Take a look at this sample on codeproject.com. I think it does what you're looking for.
I don't have the code we used to do this in front of me (assignment from a few years ago), but there are bits in the Membership API to sign someone in using code. I will not have access to the code until this weekend, unfortunately, or I could quickly share the bits and be done with this.
I do remember you had to get the user first, as a MembershipUser, using the Membership class. I am not sure, from this point, whether you had to validate against provider or what.We did use a custom provider, but I forget whether it was related to this solution.
Regardless, examine the security bits, focusing on membership and membershipUser.
Background:
I'm incorporating the SqlMembership provider into an existing system where I'm building a web front end. The Membership database will be kept in a separate database.
Beyond the login account, there's an additional mapping between the accounts that needs to be in place in the main database in order for an account to be able to log in.
Let's say that this table gives the user the right to use the system.
My question:
I would like to somehow incorporate this into the provider. Is it possible without too much work? (Or is it better to keep it in the AccountMembershipService class?)
Actually regardless, I'm very interested in learning how to put additional login requirements into the provider.
I'm asking this because when I've been looking at creating a custom membership provider earlier it seemed at that time a little bit overwhelming.
In other words:
I want to understand how to extend the Membership Provider classes in general and how to extend the login method (ValidateUser) in particular.
Given the sample ODBC implementation It looks like one simply could subclass the default provider and override ValidateUser calling base.ValidateUser as the first step.
However it may or may not be that simple, and I'd be very happy to hear any first hand experiences from implementing or extending membership providers.
I wanted to do something similar, one of the requirements was to use an Oracle DB, so I implemented the OracleMembership provider, hence I could not waste my time rewriting the hole oracle membership provider (it works pretty fine), the second requirement was to use a custom authorization legacy system. So I realized that the Internet Application template which comes with the MVC 2 or 3 comes with a small implementation of the security for the site, specifically take a look on the AccountMembershipService class. You could move all of these elements out of the MVC app to a separate assembly so you could use it even on a client implementation. The AccountMembershipService uses the Membership provider as the underlying authentication system with the option of using FormsAuthentication.
So I recommend you to take a look on that implementation. You could put your additional authentication code there so your application would stay cleaner and your don't need to re-invent the wheel and you have the chance to add your own code.
best regards
In order to extend the membership provider make you own tables with one to one relationship with the main database and handle additional requirements through this table. Also while implementing and extending the default membership provider you may need to store extra information in authcookies you may get additional information from here , here and here
In GetUserCredentials you will do your stuff for additional checking and RoleID is some dropdown on your login page that you will receive in the post method of sign in.
FormsAuth.SignIn(userName, rememberMe);
ApplicationRepository _ApplicationRepository = new ApplicationRepository();
MembershipUser aspUser = Membership.GetUser(userName);
SessionUser CurrentUser = _ApplicationRepository.GetUserCredentials(aspUser.ProviderUserKey.ToString(), RoleID);
if (CurrentUser == null)
{
ModelState.AddModelError("_FORM", "Invalid Role ");
FormsAuth.SignOut();
return View("signin");
}
I'm using asp.net 4.0 with asp.net MVC 2.0 and the asp.net membership provider.
I need to terminate a the user session before I delete it. Otherwise if the user is still authenticated the next time it will visit a page null reference exceptions will occur when trying to access the user data and profile.
I get the Session.Abandon() method but what I'm looking for is the same on a user, something like user.AbandonSessions().
I realize this question has been asked before but I can't get a straight answer.
Thanks
I think you may be tilting at windmills. There are just too many things working against your desired goal.
If you adjust your perspective to embrace the arbitrary nature of a browser based app and instead of trying to eradicate all vestiges of a users state in order to avoid errors, rather take measures to ensure that the required data is present in the session and if not then recreate it or redirect the user to an appropriate location.
In any case, remember that in order to affect any session related action capably, you must force a request cycle to ensure the cookies are properly processed by the browser, but that is beside the point I am trying to make.
Good luck.
You could use a custom membership provider which instead of deleting an account, just deactivates that. You could also have the custom membership provider to lock the account at the same time.
FormsAuthentication.SignOut();
But you need to call it in the context of the user you want to sign out.
I'm rewriting a website and going from a home-grown authentication model where users logged in with their account id (numbers) and password, to .NET FormsAuthentication where users will login with a username that they choose (or is available) and a stronger password. There are over 38K existing accounts and I'm trying to decide if the existing users should re-register or if I should write some code to do this on their behalf. I've already ruled out creating the usernames for the users because they won't be able to change their username. Luckily we don't have any users named Brenda Utthead.
If the user re-registers, some may gripe about having to do this step again and it may raise some support calls, but I stay with the standard process that everyone has to do. Or I can allow the user to login with their existing userid and password and then optionally give them a grace period to convert their account. I'm hesitant about the latter because it's special code and a possible threat vector because it bypasses the standard authentication mechanism and allows users to log in using less secure credentials.
This application currently accounts for about 40% of our website traffic and I'm not worried about users not coming back to the website because of the possibility of them having to re-register.
What does everyone think?
If you want your users to come back your best bet is to convert their accounts and send an email explaining the transition.
Do not make them re-register whatever you do.
You'll lose half of your users if you do that.
Give them a service so that they can enter their previous user id and have them provide their email address. Email them at the address provided and have them login with their email address as their new user name.
I am about to do the same thing. I am writing a migration page where the user logs in with his/her existing credentials and behind the scenes, I write out to the asp.net membership tables. Do a check first to make sure they haven't already migrated for all subsequent visits.
Don't make them re-register. A little work on your side is all it takes and you need to keep your customers happy.
After listening to everyone's suggestion, I've decided to modify the login. I look at the username they provide and try to guess that they're an existing user. Then I look them up in the old table and if I find a match take them to a conversion screen. There they can quickly convert their account or skip the whole process and login temporarily. The conversion form has fewer fields to fill out b/c I was able to authenticate them against the old user table so I don't need them to provide as much info.
I'm not thrilled with skipping the conversion but that option is only offered for the first 45 days from go-live.
Either convert them or find a way for both membership models to exist together, and somehow convert each user across at login or something.
Think about how long it took to get the 38k members and ask yourself if those were all wiped out, would those same people go through the hassle of signing up again. If you've got a really strong community you should be ok, the hit would just be a matter of time till you're built up.
The other thing you could do to mitigate the risk would be to send out a email, although spam blockers may filter them you could get to a high percentage of your users and tell them about the new membership stuff. Might get some older people back to the site as well in the process.
The biggest challenge is converting all the data that is associated with the user's accounts. People are going to be really upset if they've built up some sort of reputation that you're going to destroy with a new membership system.
This website is a check your balance type of website. It's not a banking site per se, but it exists as a convenience tool to users. I don't believe it would be realistic for users to cancel their accounts because they are forced to re-register.
I do like some of the ideas I'm reading in the responses though.
I would migrate their information and then on their first login ask them to confirm that their membership info is correct (just to be anal).
Encouraged by SO, I'm trying to write an ASP.NET site that uses OpenID for user authentication. It's a regular WinForms site (not MVC.NET), using the DotNetOpenId library for authentication.
Is it safe for me to permit/deny administrative functions on the site by simply comparing the current session's "ClaimedID" (as returned in the OpenIdLogin_LoggedIn event, as member DotNetOpenId.RelyingParty,OpenIdEventArgs.Response.ClaimedIdentifier) to a known administrator's OpenID (i.e. mine)?
If so, is it safe for this ID to be visible (e.g. in open source code), or should it be "hidden" in a configuration file or a database row? (I know it's better design to make it configurable, my question is just about safety.)
My solution is to follow the same idea of the Roles table. After you've authenticated the user, look up that user's roles. If the user has role "Administrator" in the UserRoles table, then they can do whatever the Administrator can do.
I don't broadcast open ID's in my app. They're stored in the table. On every action result, I'm hitting the Users table, since I have also modified mine to store various user state information. With the exception of the home page, there is going to be some user information that I need from that table. I'm using LINQ, so I include the .LoadWith() to load the User with his list of roles when it serializes.
Jarrett makes some good comments about using database tables.
Just to answer another one of your questions, no, it's not a confidentiality thing to put your OpenID in your code generally. If setting up roles seems overkill for your site, a simple equality check against your ClaimedIdentifier is just perfect.