Currently I have a site with usual authentication mode: login/password. The new authentication mode must be added (some number which will be verified by another system, an answer will be returned and a user will be logged in or not). So I have to store this number in my DB in addition to login/password data.
User can upgrade his/her account to use the new authentication mode, but after this the old one will not be available anymore. Only the new one will be used for the registration of new accounts.
Could you please suggest the best way to handle this situation? The simplest way in my opinion it's just save this new code in some additional property and check if this property empty or not (or add some enumeration LoginType with corresponding values).
UPDATE:
I'm wondering whether can i just use the provided above way to solve the problem or it will be a bad workaround? Also (as the second approach) I thinking about removing the current record (user account) and adding a new one with the new login name on account upgrade (when user changes the way to log in). Now I use DefaultMembershipProvider.
Thank you in advance for your answers.
Question related to ASP.NET (Web forms), not ASP.NET MVC.
Maxim
Related
I'm just looking into ASP.NET Identity, which seems that it is the most preferable solution for user authentication in ASP.NET apps these days (replacing all the ASP.NET Membership stuff from the past).
I am looking for a solution that would allow to maintain information about anonymous users. Even if the user is not authenticated, we can collect and store most of the profile data that we could store if the user was authenticated.
Even if the user is anonymous, it makes sense to store data like:
shopping cart
comments he's written on the site (so that he can edit them as their creator)
various site preferences (his preferred language, and many other settings)
Then when the user registers, we can offer to copy some of this data into his new user profile (or copy it automatically) depending on what data it is.
Is it possible to achieve this scenario with ASP.NET Identity? It seems that when a user is anonymous in ASP.NET Identity, he cannot have any user profile data.
In order to use the same tables to store all this information as for authenticated users, we might need to create a new user in the system for every new visitor that comes to the site and does some action that requires storing of some user data.
After that, we'd need to pass some cookie identifier to the user, so that we can always connect the data to the user, which can be seen as some form of authentication (although invisible to the actual user). That way, the guest user could actually represent an authenticated user of the system (maybe he'd just have a special role?), even though to his knowledge he's anonymous.
What do you think about this approach? Are there any ways where ASP.NET Identity can help with this?
I found these two related Stack Overflow questions, but I haven't found my answer in them:
Does ASP.NET Identity 2 support anonymous users?
ASP.NET Identity - Anonymous profiles
Edit:
I discovered that there's a mechanism called Anonymous Identification in ASP.NET that seems to solve part of the issue.
https://msdn.microsoft.com/en-us/library/91ka2e6a(v=vs.85).aspx
Maybe it can be somehow integrated with ASP.NET Identity?
Edit2: As noted in the comments, the documentation for Anonymous Identification seems to be outdated and it's quite probable that Microsoft will not be focusing on this much in the future. Solutions that work with ASP.NET Identity or other OWIN-based solutions are preferred.
Asp.Net Identity has no such thing, and it will not be secure identify the anonymous user even through hip IP or a Cookie in his browser, you can ask the user to register with very minimum info or through FB or Twitter to make the registration process as short as possible, and later he can complete his profile, this way you will make sure the data is linked to an actual profile.
ASP.NET profile properties allow your application to track and permanently store user-specific information. For example, users can specify a postal code or a favorite color scheme, and your application can store that information and retrieve it from anywhere in the application. ASP.NET automatically matches the current user — whether the user is anonymous or logged on — with the personal information that is stored for their user account.
Configuring Profile Properties
You will begin by configuring your application to enable profile properties. You will then define the first property that you want to track for each user. This property is named PostalCode and will be tracked for both anonymous and logged-on users.
Source: https://msdn.microsoft.com/en-us/library/taab950e.aspx
I have a site using ASP.net identity 2.0 for user management with a few external authentication options as well (google,facebook,etc).
I want to give users the option to delete their account. I found a good example of how to implement this in this answer: ASP.NET MVC 5 how to delete a user and its related data in Identity 2.0
However, I am looking to restrict anyone else from registering the old user's username when he/she delete their account. However, the email should be freed up if they decide to reregister.
I want to prevent user ABC from deleting their account, and then someone unrelated taking username ABC (this would cause confusion/problems in my use case).
I am looking for advice on best practices on how to implement this. Is there anything built into ASP identity? Or should I keep a list/sql db somewhere of all registered usernames (deleted and active) and simply check new users against this list?
Thank you.
A hyper simplistic approach would be to simply not delete the user account in the user tables but rather mark it as locked and update the email address from whatever it is to something else and set whatever other sensitive fields like passwords to in-house defaults. You'd probably want to reduce and or outright delete any rights / roles too.
So do a replace on an email account of abc#abc.com to make it abc#abc.com#deletedaccount.me.
Then you're done and dont need any extra coding as the framework will take care of the rest itself.
The off-the-shelf ASP.net Membership Provider and tables do not appear to be PCI-compliant. Has anyone already implemented a PCI-Compliant Membership Provider for ASP.net? In particular, I am looking at the requirements for section 8.5:
8.5.2: Is user identity verified before performing password resets for user requests made via non-face-to-face method?
For this I am thinking an email with a reset token valid for no more than X hours. The default provider just generates a random value and sends it via email (although we could enable Security Question/Answer to fulfill this requirement).
8.5.5: Are inactive user accounts over 90 days old either removed or disabled?
Default provider does not support this action. We could tie into the OnLoggingIn to do some checks prior to allowing to the login attempt to proceed.
8.5.9: Are use passwords changed at least every 90 days?
Should be able to check this OnLoggedIn. If last password date > 90, redirect to the password change form instead of the desired content.
8.5.12: Must an individual submit a new password that is different from any of the last four passwords he or she has used?
I do not believe the membership tables for the default providers support this. We could add a password history table and stick an entry in every time someone creates a new password. These could then be checked in the OnChangingPassword event of the ChangePassword control.
I am fully capable of doing this myself, but if there is already something out there I'd like to take advantage.
Couldn't find any out-of-box solutions, so will be following James's advice and writing my own.
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.
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.