Series hướng dẫn sử dụng asp.net identity phần 2
|
Cấu trúc các bảng sau khi tạo một ứng ASP.NET Identity, nhiều cách để tạo databse, nên sử dụng Code First để tạo database (Persistence control)
– Lưu trữ thông tin chi tiết của user, bao gồm username,password…
– Hệ thống Identity sử dụng bảng AspNetUserLogins để lưu dữ thông tin login của bên thứ 3, logins mở rộng, ví dụ người dùng login đến website thông qua Google, Facebook, Twitter…, bảng AspNetUsers là bảng chính để lưu thông tin người dùng liên kết với AspNetUserLogins qua trưởng UserId -> AspNetUsers.Id. Kết: Trong bài này mình giới thiệu về ASP.NET và lý do ra đời, giải quyết các hạn chế mà tiền nhiệm ASP.NET membership không đáp ứng được. Chốt cái hay của ASP.NET Identity: + Tính mở rộng cao + Hỗ trợ login với bên thứ 3 (các mạng xã hội như Facebook, Google, Twitter…) + Xác thực tài khoản qua email + OAuth, JWT (Json web token) Về sơ qua là vậy bạn muốn tìm hiểu sâu hơn và áp dụng nó một cách đúng đắn, hãy tham khảo link bên dưới rất chi tiết gồm lý thuyết và demo (step by step) ASP.NET Identity 2.1 is the latest membership and identity management framework provided by Microsoft, this membership system can be plugged to any ASP.NET framework such as Web API, MVC, Web Forms, etc… In this tutorial we’ll cover how to integrate ASP.NET Identity system with ASP.NET Web API , so we can build a secure HTTP service which acts as back-end for SPA front-end built using AngularJS, I’ll try to cover in a simple way different ASP.NET Identity 2.1 features such as: Accounts managements, roles management, email confirmations, change password, roles based authorization, claims based authorization, brute force protection, etc… The AngularJS front-end application will use bearer token based authentication using Json Web Tokens (JWTs) format and should support roles based authorization and contains the basic features of any membership system. The SPA is not ready yet but hopefully it will sit on top of our HTTP service without the need to come again and modify the ASP.NET Web API logic. I will follow step by step approach and I’ll start from scratch without using any VS 2013 templates so we’ll have better understanding of how the ASP.NET Identity 2.1 framework talks with ASP.NET Web API framework. The source code for this tutorial is available on GitHub.I broke down this series into multiple posts which I’ll be posting gradually, posts are:
Setting up the ASP.NET Identity 2.1Step 1: Create the Web API ProjectIn this tutorial I’m using Visual Studio 2013 and .Net framework 4.5, now create an empty solution and name it “AspNetIdentity” then add new ASP.NET Web application named “AspNetIdentity.WebApi”, we will select an empty template with no core dependencies at all, it will be as as the image below: Step 2: Install the needed NuGet Packages:We’ll install all those NuGet packages to setup our Owin server and configure ASP.NET Web API to be hosted within an Owin server, as well we will install packages needed for ASP.NET Identity 2.1, if you would like to know more about the use of each package and what is the Owin server, please check this post. Install-Package Microsoft.AspNet.Identity.Owin -Version 2.1.0 Install-Package Microsoft.AspNet.Identity.EntityFramework -Version 2.1.0 Install-Package Microsoft.Owin.Host.SystemWeb -Version 3.0.0 Install-Package Microsoft.AspNet.WebApi.Owin -Version 5.2.2 Install-Package Microsoft.Owin.Security.OAuth -Version 3.0.0 Install-Package Microsoft.Owin.Cors -Version 3.0.0 Step 3: Add Application user class and Application Database Context:Now we want to define our first custom entity framework class which is the “ApplicationUser” class, this class will represents a user wants to register in our membership system, as well we want to extend the default class in order to add application specific data properties for the user, data properties such as: First Name, Last Name, Level, JoinDate. Those properties will be converted to columns in table “AspNetUsers” as we’ll see on the next steps. So to do this we need to create new class named “ApplicationUser” and derive from “Microsoft.AspNet.Identity.EntityFramework.IdentityUser” class. Note: If you do not want to add any extra properties to this class, then there is no need to extend the default implementation and derive from “IdentityUser” class. To do so add new folder named “Infrastructure” to our project then add new class named “ApplicationUser” and paste the code below: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public class ApplicationUser : IdentityUser { [Required] [MaxLength(100)] public string FirstName { get; set; } [Required] [MaxLength(100)] public string LastName { get; set; } [Required] public byte Level { get; set; } [Required] public DateTime JoinDate { get; set; } } Now we need to add Database context class which will be responsible to communicate with our database, so add new class and name it “ApplicationDbContext” under folder “Infrastructure” then paste the code snippet below: public class ApplicationDbContext : IdentityDbContext { public ApplicationDbContext() : base("DefaultConnection", throwIfV1Schema: false) { Configuration.ProxyCreationEnabled \= false; Configuration.LazyLoadingEnabled \= false; } public static ApplicationDbContext Create() { return new ApplicationDbContext(); } } As you can see this class inherits from “IdentityDbContext” class, you can think about this class as special version of the traditional “DbContext” Class, it will provide all of the entity framework code-first mapping and DbSet properties needed to manage the identity tables in SQL Server, this default constructor takes the connection string name “DefaultConnection” as an argument, this connection string will be used point to the right server and database name to connect to. The static method “Create” will be called from our Owin Startup class, more about this later. Lastly we need to add a connection string which points to the database that will be created using code first approach, so open “Web.config” file and paste the connection string below: Step 4: Create the Database and Enable DB migrations:Now we want to enable EF code first migration feature which configures the code first to update the database schema instead of dropping and re-creating the database with each change on EF entities, to do so we need to open NuGet Package Manager Console and type the following commands: enable-migrations add-migration InitialCreate The “enable-migrations” command creates a “Migrations” folder in the “AspNetIdentity.WebApi” project, and it creates a file named “Configuration”, this file contains method named “Seed” which is used to allow us to insert or update test/initial data after code first creates or updates the database. This method is called when the database is created for the first time and every time the database schema is updated after a data model change. As well the “add-migration InitialCreate” command generates the code that creates the database from scratch. This code is also in the “Migrations” folder, in the file named “ Now back to the “Seed” method in class “Configuration”, open the class and replace the Seed method code with the code below: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 protected override void Seed(AspNetIdentity.WebApi.Infrastructure.ApplicationDbContext context) { // This method will be called after migrating to the latest version. var manager \= new UserManager var user \= new ApplicationUser() { UserName \= "SuperPowerUser", Email \= "[email protected]", EmailConfirmed \= true, FirstName \= "Taiseer", LastName \= "Joudeh", Level \= 1, JoinDate \= DateTime.Now.AddYears(-3) }; manager.Create(user, "MySuperP@ssword!"); } This code basically creates a user once the database is created. Now we are ready to trigger the event which will create the database on our SQL server based on the connection string we specified earlier, so open NuGet Package Manager Console and type the command: The “update-database” command runs the “Up” method in the “Configuration” file and creates the database and then it runs the “Seed” method to populate the database and insert a user. If all is fine, navigate to your SQL server instance and the database along with the additional fields in table “AspNetUsers” should be created as the image below: Step 5: Add the User Manager Class:The User Manager class will be responsible to manage instances of the user class, the class will derive from “UserManager Method NameUsage FindByIdAsync(id)Find user object based on its unique identifier UsersReturns an enumeration of the users FindByNameAsync(Username)Find user based on its Username CreateAsync(User, PasswordCreates a new user with a password GenerateEmailConfirmationTokenAsync(Id)Generate email confirmation token which is used in email confimration SendEmailAsync(Id, Subject, Body)Send confirmation email to the newly registered user ConfirmEmailAsync(Id, token)Confirm the user email based on the received token ChangePasswordAsync(Id, OldPassword, NewPassword)Change user password DeleteAsync(User)Delete user IsInRole(Username, Rolename)Check if a user belongs to certain Role AddToRoleAsync(Username, RoleName)Assign user to a specific Role RemoveFromRoleAsync(Username, RoleNameRemove user from specific Role Now to implement the “UserManager” class, add new file named “ApplicationUserManager” under folder “Infrastructure” and paste the code below: public class ApplicationUserManager : UserManager { public ApplicationUserManager(IUserStore : base(store) { } public static ApplicationUserManager Create(IdentityFactoryOptions { var appDbContext \= context.Get var appUserManager \= new ApplicationUserManager(new UserStore return appUserManager; } } As you notice from the code above the static method “Create” will be responsible to return an instance of the “ApplicationUserManager” class named “appUserManager”, the constructor of the “ApplicationUserManager” expects to receive an instance from the “UserStore”, as well the UserStore instance construct expects to receive an instance from our “ApplicationDbContext” defined earlier, currently we are reading this instance from the Owin context, but we didn’t add it yet to the Owin context, so let’s jump to the next step to add it. Note: In the coming post we’ll apply different changes to the “ApplicationUserManager” class such as configuring email service, setting user and password polices. Step 6: Add Owin “Startup” ClassNow we’ll add the Owin “Startup” class which will be fired once our server starts. The “Configuration” method accepts parameter of type “IAppBuilder” this parameter will be supplied by the host at run-time. This “app” parameter is an interface which will be used to compose the application for our Owin server, so add new file named “Startup” to the root of the project and paste the code below: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 public class Startup { public void Configuration(IAppBuilder app) { HttpConfiguration httpConfig \= new HttpConfiguration(); ConfigureOAuthTokenGeneration(app); ConfigureWebApi(httpConfig); app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll); app.UseWebApi(httpConfig); } private void ConfigureOAuthTokenGeneration(IAppBuilder app) { // Configure the db context and user manager to use a single instance per request app.CreatePerOwinContext(ApplicationDbContext.Create); app.CreatePerOwinContext // Plugin the OAuth bearer JSON Web Token tokens generation and Consumption will be here } private void ConfigureWebApi(HttpConfiguration config) { config.MapHttpAttributeRoutes(); var jsonFormatter \= config.Formatters.OfType jsonFormatter.SerializerSettings.ContractResolver \= new CamelCasePropertyNamesContractResolver(); } } What worth noting here is how we are creating a fresh instance from the “ApplicationDbContext” and “ApplicationUserManager” for each request and set it in the Owin context using the extension method “CreatePerOwinContext”. Both objects (ApplicationDbContext and AplicationUserManager) will be available during the entire life of the request. Note: I didn’t plug any kind of authentication here, we’ll visit this class again and add JWT Authentication in the next post, for now we’ll be fine accepting any request from any anonymous users. Define Web API Controllers and MethodsStep 7: Create the “Accounts” Controller:Now we’ll add our first controller named “AccountsController” which will be responsible to manage user accounts in our Identity system, to do so add new folder named “Controllers” then add new class named “AccountsController” and paste the code below: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 [RoutePrefix("api/accounts")] public class AccountsController : BaseApiController { [Route("users")] public IHttpActionResult GetUsers() { return Ok(this.AppUserManager.Users.ToList().Select(u \=\> this.TheModelFactory.Create(u))); } [Route("user/{id:guid}", Name \= "GetUserById")] public async Task { var user \= await this.AppUserManager.FindByIdAsync(Id); if (user != null) { return Ok(this.TheModelFactory.Create(user)); } return NotFound(); } [Route("user/{username}")] public async Task { var user \= await this.AppUserManager.FindByNameAsync(username); if (user != null) { return Ok(this.TheModelFactory.Create(user)); } return NotFound(); } } What we have implemented above is the following:
Step 8: Create the “BaseApiController” Controller:As we stated before, this “BaseApiController” will act as a base class which other Web API controllers will inherit from, for now it will contain three basic methods, so add new class named “BaseApiController” under folder “Controllers” and paste the code below: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 public class BaseApiController : ApiController { private ModelFactory _modelFactory; private ApplicationUserManager _AppUserManager \= null; protected ApplicationUserManager AppUserManager { get { return _AppUserManager ?? Request.GetOwinContext().GetUserManager } } public BaseApiController() { } protected ModelFactory TheModelFactory { get { if (_modelFactory \== null) { _modelFactory \= new ModelFactory(this.Request, this.AppUserManager); } return _modelFactory; } } protected IHttpActionResult GetErrorResult(IdentityResult result) { if (result \== null) { return InternalServerError(); } if (!result.Succeeded) { if (result.Errors != null) { foreach (string error in result.Errors) { ModelState.AddModelError("", error); } } if (ModelState.IsValid) { // No ModelState errors are available to send, so just return an empty BadRequest. return BadRequest(); } return BadRequest(ModelState); } return null; } } What we have implemented above is the following:
Step 8: Create the “ModelFactory” Class:Now add new folder named “Models” and inside this folder create new class named “ModelFactory”, this class will contain all the functions needed to shape the response object and control the object graph returned to the client, so open the file and paste the code below: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 public class ModelFactory { private UrlHelper _UrlHelper; private ApplicationUserManager _AppUserManager; public ModelFactory(HttpRequestMessage request, ApplicationUserManager appUserManager) { _UrlHelper \= new UrlHelper(request); _AppUserManager \= appUserManager; } public UserReturnModel Create(ApplicationUser appUser) { return new UserReturnModel { Url \= _UrlHelper.Link("GetUserById", new { id \= appUser.Id }), Id \= appUser.Id, UserName \= appUser.UserName, FullName \= string.Format("{0} {1}", appUser.FirstName, appUser.LastName), Email \= appUser.Email, EmailConfirmed \= appUser.EmailConfirmed, Level \= appUser.Level, JoinDate \= appUser.JoinDate, Roles \= _AppUserManager.GetRolesAsync(appUser.Id).Result, Claims \= _AppUserManager.GetClaimsAsync(appUser.Id).Result }; } } public class UserReturnModel { public string Url { get; set; } public string Id { get; set; } public string UserName { get; set; } public string FullName { get; set; } public string Email { get; set; } public bool EmailConfirmed { get; set; } public int Level { get; set; } public DateTime JoinDate { get; set; } public IList public IList } Notice how we included only the properties needed to return them in users object graph, for example there is no need to return the “PasswordHash” property so we didn’t include it. Step 9: Add Method to Create Users in”AccountsController”:It is time to add the method which allow us to register/create users in our Identity system, but before adding it, we need to add the request model object which contains the user data which will be sent from the client, so add new file named “AccountBindingModels” under folder “Models” and paste the code below: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 public class CreateUserBindingModel { [Required] [EmailAddress] [Display(Name \= "Email")] public string Email { get; set; } [Required] [Display(Name \= "Username")] public string Username { get; set; } [Required] [Display(Name \= "First Name")] public string FirstName { get; set; } [Required] [Display(Name \= "Last Name")] public string LastName { get; set; } [Display(Name \= "Role Name")] public string RoleName { get; set; } [Required] [StringLength(100, ErrorMessage \= "The {0} must be at least {2} characters long.", MinimumLength \= 6)] [DataType(DataType.Password)] [Display(Name \= "Password")] public string Password { get; set; } [Required] [DataType(DataType.Password)] [Display(Name \= "Confirm password")] [Compare("Password", ErrorMessage \= "The password and confirmation password do not match.")] public string ConfirmPassword { get; set; } } The class is very simple, it contains properties for the fields we want to send from the client to our API with some data annotation attributes which help us to validate the model before submitting it to the database, notice how we added property named “RoleName” which will not be used now, but it will be useful in the coming posts. Now it is time to add the method which register/creates a user, open the controller named “AccountsController” and add new method named “CreateUser” and paste the code below: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 [Route("create")] public async Task { if (!ModelState.IsValid) { return BadRequest(ModelState); } var user \= new ApplicationUser() { UserName \= createUserModel.Username, Email \= createUserModel.Email, FirstName \= createUserModel.FirstName, LastName \= createUserModel.LastName, Level \= 3, JoinDate \= DateTime.Now.Date, }; IdentityResult addUserResult \= await this.AppUserManager.CreateAsync(user, createUserModel.Password); if (!addUserResult.Succeeded) { return GetErrorResult(addUserResult); } Uri locationHeader \= new Uri(Url.Link("GetUserById", new { id \= user.Id })); return Created(locationHeader, TheModelFactory.Create(user)); } What we have implemented here is the following:
Notes:
Step 10: Test Methods in”AccountsController”:Lastly it is time to test the methods added to the API, so fire your favorite REST client Fiddler or PostMan, in my case I prefer PostMan. So lets start testing the “Create” user method, so we need to issue HTTP Post to the URI: “http://localhost:59822/api/accounts/create” as the request below, if creating a user went good you will receive 201 response: Now to test the method “GetUsers” all you need to do is to issue HTTP GET to the URI: “http://localhost:59822/api/accounts/users” and the response graph will be as the below: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 [ { "url": "http://localhost:59822/api/accounts/user/29e21f3d-08e0-49b5-b523-3d68cf623fd5", "id": "29e21f3d-08e0-49b5-b523-3d68cf623fd5", "userName": "SuperPowerUser", "fullName": "Taiseer Joudeh", "email": "[email protected]", "emailConfirmed": true, "level": 1, "joinDate": "2012-01-17T12:41:40.457", "roles": [ "Admin", "Users", "SuperAdmin" ], "claims": [ { "issuer": "LOCAL AUTHORITY", "originalIssuer": "LOCAL AUTHORITY", "properties": {}, "subject": null, "type": "Phone", "value": "123456782", "valueType": "http://www.w3.org/2001/XMLSchema string"}, { "issuer": "LOCAL AUTHORITY", "originalIssuer": "LOCAL AUTHORITY", "properties": {}, "subject": null, "type": "Gender", "value": "Male", "valueType": "http://www.w3.org/2001/XMLSchema string"} ] }, { "url": "http://localhost:59822/api/accounts/user/f0f8d481-e24c-413a-bf84-a202780f8e50", "id": "f0f8d481-e24c-413a-bf84-a202780f8e50", "userName": "tayseer.Joudeh", "fullName": "Tayseer Joudeh", "email": "[email protected]", "emailConfirmed": true, "level": 3, "joinDate": "2015-01-17T00:00:00", "roles": [], "claims": [] } ] The source code for this tutorial is available on GitHub.In the next post we’ll see how we’ll configure our Identity service to start sending email confirmations, customize username and password polices, implement Json Web Token (JWTs) Authentication and manage the access for the methods. |
