When calling UserManager.GenerateEmailConfirmationToken() I get a token, but the ConfirmationToken column in AspNetUsers table is left empty. Does this method suppose to put the token there automatically, and if so where do I tell it the name of the column to look for. Or maybe I need to manually put the token there myself after calling it ?
(Also the EmailConfirmed column in AspNetUsers stays False after calling UserManager.ConfirmEmail but I presume it happens for the same reasons).
There is no ConfirmationToken column by default in Identity 2.0, are you sure this isn't something you added in your user class?
Related
i am working on ASP.Net 5 , web api project and using Microsoft Identity and jwt token based for my security management . I have already extended the user claim table and add a new row of isSelected to this table . I need to know , how can i just get the claims that has the isSelected == true from the table , is there any way that i can use the _signinManager services for this task? I can do like this for normal situation :
var claims = await _signinManager.ClaimsFactory.CreateAsync(user)
and get the ClaimPrincipals , but this will return all the claims whether the isSelected is true or false .
Thank you!
Some behaviors require customization. Like in your case, you want the default configuration to filter list of data based on a particular column name (isSelected) and only return the filtered list. The best way to approach this using a customized UserManager or SignInManager and create a method that will do just what you're asking for.
Here's an idea:
Create a method called IList<UserClaim> GetUserClaimsBasedOnSelection(bool isSelected, User user). All that this method should do is use the underlying Claims retrieving method and just filter that list to only return the selected claims. That's it. And then after you just register your configured SignInManager inside Program.cs or startup.cs by adding this service to your AddIdentity service configuration .AddSignInManager<YourSignInManager>()
While developing a multi-tenant app with ASP.NET Core I noticed that it brings 2 new indices: NormalizedUserName & NormalizedEmail.
The main problem is that it gets too difficult to have a unique user per tenant.
What I mean is having multiple users with the same UserName & Email but different TenantID.
In order to achieve this I have to remove those indices
public static void RemoveIndexes(this ModelBuilder modelBuilder)
{
modelBuilder.Entity<ApplicationUser>(entity =>
{
var normalizedUserNameIndex = entity.HasIndex(u => new { u.NormalizedUserName }).Metadata;
entity.Metadata.RemoveIndex(normalizedUserNameIndex.Properties);
var normalizedEmailIndex = entity.HasIndex(u => new { u.NormalizedEmail }).Metadata;
entity.Metadata.RemoveIndex(normalizedEmailIndex.Properties);
});
}
My questions are:
What is the purpose of these 2 new indices?
What would it affect if we just remove them?
Is there anything we need to pay close attention to after removing them? (e.g. overriding default UserManager functionality or something to that effect)
First of all, I wouldn't change anything of the Identity Framework if I can't oversee the effects. If you insist, you can test what happens yourself. But, do you need to remove the fields?
If the relation of user-to-tenant is one-to-many, then tenantId should not be a field of ApplicationUser but rather be stored in a seperate table, like UserClaims.
You can add multiple tenantId's as claim of the same type, like http://tenant.company.com/Id. It will then become a collection of values, like what happens with roles.
If you don't want this then you can use different claimtypes, like http://tenant.company1.com/Id, http://tenant.company2.com/Id or something like that.
You can choose to include only claims that are linked to the tenant, which could be determined from the site binding or the url, for instance.
This design allows the user to login using the same password everywhere. Please note, this is about identity: who is the user? The user doesn't need to have a different password for every tenant.
It also makes it easier to change a password. Because I wonder, how does your scenario look like with multiple user records for each tenant? Will you update all records at once when a password changes? And how will you support 'forgot password' and other features?
Why do I want this?
I'm trying to get a unique identifier from my user which I can connect to database records. There are reasons I don't want to use the Email as the identifier. I read that SUB claim isn't supported with B2C, and to use OID in it's place.
Steps I've Taken
So, I've set up that both of my policies return Object ID on Azure B2C:
I'm using individual SignIn and SignUp policies at the moment, and I get all of the claims back, including the email claim which I specified I wanted to be returned. I cannot however find a claim related to OID or SUB.
User.Claims
Nets me the following results:
The single breadcrumb of hope that I have found is this claim:
Type: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
Value: Not supported currently. Use oid claim.
Questions
Have I missed some additional step that you need to perform to retrieve this particular claim?
Has anyone had any success retrieving an OID or SUB from Azure B2C?
Well, this is embarrassing, I must have looked over this line about 30 times and not noticed...
I was retrieving the OID token, it's claim type was:
http://schemas.microsoft.com/identity/claims/objectidentifier
As can be clearly seen in my provided screenshots. I'll leave this question up as, the schema may throw someone else off.
I struggled with this for a little while and this post helped me.
To update things with some code, the below will obtain the object identifier value (unique user id in Azure)
User.FindFirst("http://schemas.microsoft.com/identity/claims/objectidentifier").Value
Thanks for pointing out the differences in the schema/types!
If you are using the Microsoft.Identity.Web package there is now a ClaimsPrincipalExtensions class that provides an extension method, so that you can simply use:
// using Microsoft.Identity.Web;
User.GetObjectId();
This uses the oid or http://schemas.microsoft.com/identity/claims/objectidentifier claim.
Since the links above are broken and this is something that I really struggled to find a working example of, here is a code fragment of what I ended up using;
using System.IdentityModel.Tokens.Jwt;
...
string oid;
string pTokenInput = Request.Headers["x-ms-token-aad-id-token"].ToString();
var lJWTHandler = new JwtSecurityTokenHandler();
if (lJWTHandler.CanReadToken(pTokenInput)
{
var lToken = lJWTHandler.ReadJwtToken(pTokenInput);
if (lToken.Payload.ContainsKey("oid"))
oid = lToken.Payload["oid"].ToString();
}
Hopefully, this will help someone else...
It seems that you do not necessarily need object-identifier here.
When debugging, I see that the value of object-identifier is mapped to nameidentifier
Which is accessible with the built-in constant NameIdentifier:
var identity = authState.User.Identity as System.Security.Claims.ClaimsIdentity;
var userId = identity.FindFirst(System.Security.Claims.ClaimTypes.NameIdentifier).Value;
Suppose I am updating a employee record
url - /api/employees/10
body -
{
id : 10,
name : xyz
}
Should I validate for the employee id in url is same as in response? Because one employee can hit the url himself but update the data of another employee by sending another value in the PUT body.
If you have to validate, it's likely that you want to use POST. A POST is not idempotent and you are supposed to manage the change.
PUT is idempotent, and it just creates a resource. It implies that you don't actually care what id 10 is and whether it is a new id or an existing id. You just replace id 10 with the resource you supply. You only use PUT when you know what the uri should be.
Yes, if the representation of the object in the body contains its own key, you should validate that it matches the key from the URL. It's an error for the client to try to PUT an object at /api/employees/10 that isn't a valid value for employee #10's record, so you should check for that and report it as an error just as you would check that the object has correct syntax.
I believe that the best error code to return in this case is 422 Unprocessable Entity, but I might be wrong about that.
Another thing you can do instead is don't include the key at all in the body. However I find that keeping the key in makes sense for consistency with the way the same type of object is represented in other parts of the API (possibly embedded inside other objects). This is especially true when using XML (although it looks like you are using JSON here).
My Users table (the one that I created) has the following columns:
UserId,UserName,FirstName,LastName,DOB
After I ran this command
WebSecurity.InitializeDatabaseConnection("DefaultConnection", "Users", "UserId", "UserName", autoCreateTables: true);
it created the required simple membership tables for me.
How would I go about "UnConfirming" an user or setting the "IsConfirmed" flag to false in the webpages_Membership using the new SimpleMembership API?
(Earlier, before going to simplemembership using the "Membership" class I could update an user using the api call : Membership.UpdateUser( user );)
I can't answer your question directly since I couldn't figure out a way to 'unconfirm' an account either. What I ended up doing, however, may help whoever finds this question.
I basically use Roles as a gatekeeper. Whenever I create a new account I add that user to a "User" role:
Roles.AddUserToRole(newUser.Username, "User");
I use the Authorize attribute to restrict access to my controllers (and use [AllowAnonymous] for actions that I want to be public -- like RegisterUser, for example). Then, inside each action I add a method to restrict access to only users that are in the "User" role.
if (!Roles.IsUserInRole(role))
{
throw new HttpResponseException(
new HttpResponseMessage(HttpStatusCode.Unauthorized));
}
NOTE: I'm using Web API, but if you're using MVC you should have a much easier time. Instead of manually checking if a user is in a role in each action you can just use the authorize attribute:
[Authorize(Roles = "User")]
When I want to "UnConfirm" a user I just remove them from the "User" role.
Roles.RemoveUserFromRole(user.Username, "User");
This way if a user comes crawling back I can just reactivate their account by adding them back as a User.
What I ended up doing was updating that table directly via a SQL query. Not sure if thats the recommended way of doing it, but that seemed to work for me.
(Thanks for your suggestion too).
Look at this blog post on adding email confirmation to SimpleMembership registration process, which covers how the confirmation process works. The cliff notes are that when you create a new user you set the flag that you want to use confirmation like this.
string confirmationToken =
WebSecurity.CreateUserAndAccount(model.UserName, model.Password, new { Email = model.Email }, true);
When you do this the CreateUserAndAccount method returns a unique token that you can put in an email with a link so the user can confirm that they gave you a valid email address. When they click on the link it passes the token in the URL and the controller action can then confirm the token like this.
[AllowAnonymous]
public ActionResult RegisterConfirmation(string Id)
{
if (WebSecurity.ConfirmAccount(Id))
{
return RedirectToAction("ConfirmationSuccess");
}
return RedirectToAction("ConfirmationFailure");
}
The ConfirmAccount method checks if there is an uncomfirmed token that matches in the database and if there is it sets the isConfirmed flag to true. The user will not be able to logon until this is set to true.
set requireConfirmationToken to be true: (The 4th value shown below)
WebSecurity.CreateUserAndAccount(viewModel.UserName, viewModel.Password, null, true);
Source
http://www.w3schools.com/aspnet/met_websecurity_createuserandaccount.asp