I'm using MVC5, identity 2.0.0. There is email registration with email confirmation. It is possible to get or set confirmation validity?
I think, it is wrong when people has registred by his email address and he can confirm it after one year, or he never confirm this address, because email belongs to other people.
This is probably not the answer you want, but based on some research it looks like this is an area that still needs some development in ASP.NET Identity.
This guy basically says that .NET Identity has got a long way to go, and lists email verification as a weak point of the library, but that was before 2.0.0 came out.
The Windows Azure website has an example application using Identity, but it doesn't seem to have email verification built in.
This guy has an example that is closer to what you want with email verification. But it would take some additional enhancements to get to where you want to be. And I'm not sure if he is using Identity 2. You might would want to add a date stamp, and disallow verifications that come in after a certain window of time.
Lastly, the Microsoft ASP.NET website has a request in for a full example of using email verification with Identity 2.0. But as of now, it is still under review.
edit June 5, 2014
To follow up on this question, it looks like the ASP.Net team has put together a couple of walkthroughs for setting up email account verification with Identity. Check out the links
here (http://www.asp.net/identity/overview/features-api/account-confirmation-and-password-recovery-with-aspnet-identity)
and here (http://www.asp.net/identity/overview/features-api/two-factor-authentication-using-sms-and-email-with-aspnet-identity).
Related
I'm using ASP.NET Identity in my project. After my user logs in with her FB account she needs to input her email.. I've never met FB auth process that would work like that on any sites but even Microsoft really believes this is necessary is there any easy way to rid of this step?
There is a property on User called something like "EmailConfirmed". You can set this to true and remove any code for sending confirmation email from the boiler plate code. Email is a required field on the data model though, so FB needs to give you this.
I've started an ASP.NET web site in Visual Studio using a Microsoft pre-defined template. This is to help me learn about OpenID within ASP.NET.
Inside the included SQL database within the sample site, there is a table called UsersOpenAuthAccounts that contains a column called ProviderUserName.
Can anyone tell me the purpose of this column? In my tests, this seems to store the username that I would log into an OpenID site with (e.g. my Google username - my email address). However, I also see that the ProviderUserId column holds the IAuthenticationResponse.ClaimedIdentifier value, e.g.
https://www.google.com/accounts/o8/id?id=AIt................g3c
...which would be used to identify the user against the OpenID provider for future requests.
Therefore, is there any point in including the ProviderUserName column? It's not actually used anywhere else within Microsoft's sample site.
ProviderUserName is... a bad idea (IMO).
The OpenID Claimed Identifier is the right string to check for return users. It reduces security to use anything else, including email address. If you're only interested in OpenID logins then you may want to just throw out the ASP.NET provided code and use DotNetOpenAuth's OpenIdRelyingParty directly and deal with the users table yourself. It will be about as simple as your current code, but without the unnecessary columns.
What the ASP.NET team's additional column and façade classes give you is the ability to mix OpenID logins with OAuth logins, which allow you to accept Twitter and Facebook accounts at your site as well. OAuth wasn't designed to be an authentication protocol, so those who use it have to make up their own idea of a username. In order for that to be globally unique, it must be prefixed by the provider who is issuing that username. So you have ProviderName ("twitter" or "google") and a ProviderUsername which is the username (or user id perhaps) of the account from the OAuth service provider.
We're currently using forms authentication for our intranet site and would like to allow users to authenticate via windows authentication instead. How will this affect current user accounts, profiles and roles. I have seen on the web that I can mix the two authentication types and put roles and profiles in a separate DB, but how do I link up existing role and profile assignments with windows authentication user logins?
I'm not sure if you can do it exactly what you are asking however you could code your way out of this, you could write functionality that requires people who are windows authenticated to enter a credential you already have on file which is unique (say an email address) you could then convert the user account programatically if they responded by clicking a link.
You could create the new account and import the information from the old non windows authenticated account and then delete the old account. All db records that relyon UserId however would need to be changed in this approach as part of migration.
Depends on how integrated you want to be but if it's single sign on that't driving this.
get the user's sid look for it in profiles roles etc (could add sid column to them but a simple sid - userid table would be better.
if they are in there you are good to go.
if they aren't use the forms athentication to identify them and add a mapping from their sid touserid. So they'll get asked once more and thats it.
You'll probably need a similar mechanism anyway, in the event of the sid changing, which can happen after various windows issues. or for say anonymous access for non windows users.
if you don't like sid as an id then some other e.g domain\user name might do it.
windows groups/roles to application roles for full integration is another step, as would
rationalising profile info like full name etc..
it's nice quick start any way without having to trawl through everything that uses user id now and change it.
Finally coming back around to answer the question. We actually kind of scrapped what we had in our Forms Authentication. The Roles work pretty differently with Windows authentication, as does the profile. We used a custom profile provider rather than the built in profile provider. If anyone is interested in what we've done, I put together a series of four blog posts that detail what we did in our environment and some of the glitches we ran into: Part 1, Part 2, Part 3 and Part 4.
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.
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.