فعالسازی Windows Authentication در IIS
پس از publish برنامه و رعایت مواردی که در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 22 - توزیع برنامه توسط IIS» بحث شد، باید به قسمت Authentication برنامهی مدنظر، در کنسول مدیریتی IIS رجوع کرد:
و سپس Windows Authentication را با کلیک راست بر روی آن و انتخاب گزینهی Enable، فعال نمود:
این تنظیم دقیقا معادل افزودن تنظیمات ذیل به فایل web.config برنامه است:
<system.webServer> <security> <authentication> <anonymousAuthentication enabled="true" /> <windowsAuthentication enabled="true" /> </authentication> </security> </system.webServer>
فعالسازی Windows Authentication در IIS Express
اگر برای آزمایش میخواهید از IIS Express به همراه ویژوال استودیو استفاده کنید، نیاز است فایلی را به نام Properties\launchSettings.json با محتوای ذیل در ریشهی پروژهی خود ایجاد کنید (و یا تغییر دهید):
{ "iisSettings": { "windowsAuthentication": true, "anonymousAuthentication": true, "iisExpress": { "applicationUrl": "http://localhost:3381/", "sslPort": 0 } } }
تغییر مهم فایل web.config برنامه جهت هدایت اطلاعات ویندوز به آن
اگر پروژهی شما فایل web.config ندارد، باید آنرا اضافه کنید؛ با حداقل محتوای ذیل:
<?xml version="1.0" encoding="utf-8"?> <configuration> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/> </handlers> <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="true"/> </system.webServer> </configuration>
تنظیمات برنامهی ASP.NET Core جهت فعالسازی Windows Authentication
پس از فعالسازی windowsAuthentication در IIS و همچنین تنظیم forwardWindowsAuthToken به true در فایل web.config برنامه، اکنون جهت استفادهی از windowsAuthentication دو روش وجود دارد:
الف) تنظیمات مخصوص برنامههای Self host
اگر برنامهی وب شما قرار است به صورت self host ارائه شود (بدون استفاده از IIS)، تنها کافی است در تنظیمات ابتدای برنامه در فایل Program.cs، استفادهی از میانافزار HttpSys را ذکر کنید:
namespace ASPNETCore2WindowsAuthentication { public class Program { public static void Main(string[] args) { var host = new WebHostBuilder() .UseKestrel() .UseContentRoot(Directory.GetCurrentDirectory()) .UseStartup<Startup>() .UseHttpSys(options => // Just for local tests without IIS, Or self-hosted scenarios on Windows ... { options.Authentication.Schemes = AuthenticationSchemes.Negotiate | AuthenticationSchemes.NTLM; options.Authentication.AllowAnonymous = true; //options.UrlPrefixes.Add("http://+:80/"); }) .Build(); host.Run(); } } }
ب) تنظیمات مخصوص برنامههایی که قرار است در IIS هاست شوند
در اینحالت تنها کافی است UseIISIntegration در تنظیمات ابتدایی برنامه ذکر شود و همانطور که عنوان شد، نیازی به UseHttpSys در این حالت نیست:
namespace ASPNETCore2WindowsAuthentication { public class Program { public static void Main(string[] args) { var host = new WebHostBuilder() .UseKestrel() .UseContentRoot(Directory.GetCurrentDirectory()) .UseIISIntegration() .UseDefaultServiceProvider((context, options) => { options.ValidateScopes = context.HostingEnvironment.IsDevelopment(); }) .UseStartup<Startup>() .Build(); host.Run(); } } }
فعالسازی میانافزار اعتبارسنجی ASP.NET Core جهت یکپارچه شدن با Windows Authentication
در پایان تنظیمات فعالسازی Windows Authentication نیاز است به فایل Startup.cs برنامه مراجعه کرد و یکبار AddAuthentication را به همراه تنظیم ChallengeScheme آن به IISDefaults افزود:
public void ConfigureServices(IServiceCollection services) { services.AddMvc(); services.Configure<IISOptions>(options => { // Sets the HttpContext.User // Note: Windows Authentication must also be enabled in IIS for this to work. options.AutomaticAuthentication = true; options.ForwardClientCertificate = true; }); services.AddAuthentication(options => { // for both windows and anonymous authentication options.DefaultChallengeScheme = IISDefaults.AuthenticationScheme; }); }
آزمایش برنامه با تدارک یک کنترلر محافظت شده
در اینجا قصد داریم اطلاعات ذیل را توسط تعدادی اکشن متد، نمایش دهیم:
private string authInfo() { var claims = new StringBuilder(); if (User.Identity is ClaimsIdentity claimsIdentity) { claims.Append("Your claims: \n"); foreach (var claim in claimsIdentity.Claims) { claims.Append(claim.Type + ", "); claims.Append(claim.Value + "\n"); } } return $"IsAuthenticated: {User.Identity.IsAuthenticated}; Identity.Name: {User.Identity.Name}; WindowsPrincipal: {(User is WindowsPrincipal)}\n{claims}"; }
namespace ASPNETCore2WindowsAuthentication.Controllers { public class HomeController : Controller { public IActionResult Index() { return View(); } [Authorize] public IActionResult Windows() { return Content(authInfo()); } private string authInfo() { var claims = new StringBuilder(); if (User.Identity is ClaimsIdentity claimsIdentity) { claims.Append("Your claims: \n"); foreach (var claim in claimsIdentity.Claims) { claims.Append(claim.Type + ", "); claims.Append(claim.Value + "\n"); } } return $"IsAuthenticated: {User.Identity.IsAuthenticated}; Identity.Name: {User.Identity.Name}; WindowsPrincipal: {(User is WindowsPrincipal)}\n{claims}"; } [AllowAnonymous] public IActionResult Anonymous() { return Content(authInfo()); } [Authorize(Roles = "Domain Admins")] public IActionResult ForAdmins() { return Content(authInfo()); } [Authorize(Roles = "Domain Users")] public IActionResult ForUsers() { return Content(authInfo()); } } }
dotnet publish
اکنون اگر برنامه را در مرورگر مشاهده کنیم، یک چنین خروجی قابل دریافت است:
در اینجا نام کاربر وارد شدهی به ویندوز و همچنین لیست تمام Claims او مشاهده میشوند. مسیر Home/Windows نیز توسط ویژگی Authorize محافظت شدهاست.
برای محدود کردن دسترسی کاربران به اکشن متدها، توسط گروههای دومین و اکتیودایرکتوری، میتوان به نحو ذیل عمل کرد:
[Authorize(Roles = @"<domain>\<group>")] //or [Authorize(Roles = @"<domain>\<group1>,<domain>\<group2>")]
services.AddAuthorization(options => { options.AddPolicy("RequireWindowsGroupMembership", policy => { policy.RequireAuthenticatedUser(); policy.RequireRole(@"<domain>\<group>")); } });
[Authorize(Policy = "RequireWindowsGroupMembership")]
[HttpGet("[action]")] public IActionResult SomeValue() { if (!User.IsInRole(@"Domain\Group")) return StatusCode(403); return Ok("Some Value"); }
افزودن Claims سفارشی به Claims پیشفرض کاربر سیستم
همانطور که در شکل فوق ملاحظه میکنید، یک سری Claims حاصل از Windows Authentication در اینجا به شیء User اضافه شدهاند؛ بدون اینکه برنامه، صفحهی لاگینی داشته باشد و همینقدر که کاربر به ویندوز وارد شدهاست، میتواند از برنامه استفاده کند.
اگر نیاز باشد تا Claims خاصی به لیست Claims کاربر جاری اضافه شود، میتوان از پیاده سازی یک IClaimsTransformation سفارشی استفاده کرد:
public class ApplicationClaimsTransformation : IClaimsTransformation { private readonly ILogger<ApplicationClaimsTransformation> _logger; public ApplicationClaimsTransformation(ILogger<ApplicationClaimsTransformation> logger) { _logger = logger; } public Task<ClaimsPrincipal> TransformAsync(ClaimsPrincipal principal) { if (!(principal.Identity is ClaimsIdentity identity)) { return Task.FromResult(principal); } var claims = addExistingUserClaims(identity); identity.AddClaims(claims); return Task.FromResult(principal); } private IEnumerable<Claim> addExistingUserClaims(IIdentity identity) { var claims = new List<Claim>(); var user = @"VahidPC\Vahid"; if (identity.Name != user) { _logger.LogError($"Couldn't find {identity.Name}."); return claims; } claims.Add(new Claim(ClaimTypes.GivenName, user)); return claims; } }
services.AddScoped<IClaimsTransformation, ApplicationClaimsTransformation>(); services.AddAuthentication(options => { // for both windows and anonymous authentication options.DefaultChallengeScheme = IISDefaults.AuthenticationScheme; });
به این ترتیب میتوان لیست Claims ثبت شدهی یک کاربر را در یک بانک اطلاعاتی استخراج و به لیست Claims فعلی آن افزود و دسترسیهای بیشتری را به او اعطاء کرد (فراتر از دسترسیهای پیشفرض سیستم عامل).
برای دسترسی به مقادیر این Claims نیز میتوان به صورت ذیل عمل کرد:
var userId = User.FindFirstValue(ClaimTypes.NameIdentifier); var userName = User.FindFirstValue(ClaimTypes.Name); var userName = User.FindFirstValue(ClaimTypes.GivenName);
کدهای کامل این برنامه را از اینجا میتوانید دریافت کنید: ASPNETCore2WindowsAuthentication.zip
تعریف موجودیتهای مورد نیاز جهت طراحی یک سیستم اعتبارسنجی
در اینجا کنترل کامل سیستم در اختیار ما است و در این حالت میتوان طراحی تمام قسمتها را از ابتدا و مطابق میل خود انجام داد. برای مثال سیستم اعتبارسنجی سادهی ما، شامل جدول کاربران و نقشهای آنها خواهد بود و این دو با هم رابطهی many-to-many دارند. به همین جهت جدول UserRole نیز در اینجا پیش بینی شدهاست.
جدول کاربران
public class User { public User() { UserRoles = new HashSet<UserRole>(); } public int Id { get; set; } public string Username { get; set; } public string Password { get; set; } public string DisplayName { get; set; } public bool IsActive { get; set; } public DateTimeOffset? LastLoggedIn { get; set; } /// <summary> /// every time the user changes his Password, /// or an admin changes his Roles or stat/IsActive, /// create a new `SerialNumber` GUID and store it in the DB. /// </summary> public string SerialNumber { get; set; } public virtual ICollection<UserRole> UserRoles { get; set; } }
جدول نقشهای کاربران
public class Role { public Role() { UserRoles = new HashSet<UserRole>(); } public int Id { get; set; } public string Name { get; set; } public virtual ICollection<UserRole> UserRoles { get; set; } }
public static class CustomRoles { public const string Admin = nameof(Admin); public const string User = nameof(User); }
جدول ارتباط نقشها با کاربران و برعکس
public class UserRole { public int UserId { get; set; } public int RoleId { get; set; } public virtual User User { get; set; } public virtual Role Role { get; set; } }
تعریف Context برنامه و فعالسازی Migrations در EF Core 2.0
DbContext برنامه را به صورت ذیل در یک اسمبلی دیگر اضافه خواهیم کرد:
public interface IUnitOfWork : IDisposable { DbSet<TEntity> Set<TEntity>() where TEntity : class; int SaveChanges(bool acceptAllChangesOnSuccess); int SaveChanges(); Task<int> SaveChangesAsync(bool acceptAllChangesOnSuccess, CancellationToken cancellationToken = new CancellationToken()); Task<int> SaveChangesAsync(CancellationToken cancellationToken = new CancellationToken()); } public class ApplicationDbContext : DbContext, IUnitOfWork { public ApplicationDbContext(DbContextOptions options) : base(options) { } public virtual DbSet<User> Users { set; get; } public virtual DbSet<Role> Roles { set; get; } public virtual DbSet<UserRole> UserRoles { get; set; } protected override void OnModelCreating(ModelBuilder builder) { // it should be placed here, otherwise it will rewrite the following settings! base.OnModelCreating(builder); // Custom application mappings builder.Entity<User>(entity => { entity.Property(e => e.Username).HasMaxLength(450).IsRequired(); entity.HasIndex(e => e.Username).IsUnique(); entity.Property(e => e.Password).IsRequired(); entity.Property(e => e.SerialNumber).HasMaxLength(450); }); builder.Entity<Role>(entity => { entity.Property(e => e.Name).HasMaxLength(450).IsRequired(); entity.HasIndex(e => e.Name).IsUnique(); }); builder.Entity<UserRole>(entity => { entity.HasKey(e => new { e.UserId, e.RoleId }); entity.HasIndex(e => e.UserId); entity.HasIndex(e => e.RoleId); entity.Property(e => e.UserId); entity.Property(e => e.RoleId); entity.HasOne(d => d.Role).WithMany(p => p.UserRoles).HasForeignKey(d => d.RoleId); entity.HasOne(d => d.User).WithMany(p => p.UserRoles).HasForeignKey(d => d.UserId); }); } }
سازندهی کلاس به همراه پارامتر DbContextOptions است تا بتوان آنرا در آغاز برنامه تغییر داد.
فعالسازی مهاجرتها در EF Core 2.0
EF Core 2.0 برخلاف نگارشهای قبلی آن به دنبال کلاسی مشتق شدهی از IDesignTimeDbContextFactory میگردد تا بتواند نحوهی وهله سازی ApplicationDbContext را دریافت کند. در اینجا چون DbContext تعریف شده دارای یک سازندهی با پارامتر است، EF Core 2.0 نمیداند که چگونه باید آنرا در حین ساخت مهاجرتها و اعمال آنها، وهله سازی کند. کار کلاس ApplicationDbContextFactory ذیل دقیقا مشخص سازی همین مساله است:
/// <summary> /// Only used by EF Tooling /// </summary> public class ApplicationDbContextFactory : IDesignTimeDbContextFactory<ApplicationDbContext> { public ApplicationDbContext CreateDbContext(string[] args) { var basePath = Directory.GetCurrentDirectory(); Console.WriteLine($"Using `{basePath}` as the BasePath"); var configuration = new ConfigurationBuilder() .SetBasePath(basePath) .AddJsonFile("appsettings.json") .Build(); var builder = new DbContextOptionsBuilder<ApplicationDbContext>(); var connectionString = configuration.GetConnectionString("DefaultConnection"); builder.UseSqlServer(connectionString); return new ApplicationDbContext(builder.Options); } }
{ "ConnectionStrings": { "DefaultConnection": "Data Source=(LocalDB)\\MSSQLLocalDB;Initial Catalog=ASPNETCore2CookieAuthenticationDB;Integrated Security=True;MultipleActiveResultSets=True;" }, "LoginCookieExpirationDays": 30 }
کار یافتن این کلاس در حین تدارک و اعمال مهاجرتها توسط EF Core 2.0 خودکار بوده و باید محل قرارگیری آن دقیقا در اسمبلی باشد که DbContext برنامه در آن تعریف شدهاست.
تدارک لایه سرویسهای برنامه
پس از مشخص شدن ساختار موجودیتها و همچنین Context برنامه، اکنون میتوان لایه سرویس برنامه را به صورت ذیل تکمیل کرد:
سرویس کاربران
public interface IUsersService { Task<string> GetSerialNumberAsync(int userId); Task<User> FindUserAsync(string username, string password); Task<User> FindUserAsync(int userId); Task UpdateUserLastActivityDateAsync(int userId); }
پیاده سازی کامل این سرویس را در اینجا میتوانید مشاهده کنید.
سرویس نقشهای کاربران
public interface IRolesService { Task<List<Role>> FindUserRolesAsync(int userId); Task<bool> IsUserInRole(int userId, string roleName); Task<List<User>> FindUsersInRoleAsync(string roleName); }
پیاده سازی کامل این سرویس را در اینجا میتوانید مشاهده کنید.
سرویس آغاز بانک اطلاعاتی
public interface IDbInitializerService { void Initialize(); void SeedData(); }
پیاده سازی کامل این سرویس را در اینجا میتوانید مشاهده کنید.
سرویس اعتبارسنجی کوکیهای کاربران
یکی از قابلیتهای میانافزار اعتبارسنجی ASP.NET Core 2.0، رخدادی است که در آن اطلاعات کوکی دریافتی از کاربر، رمزگشایی شده و در اختیار برنامه جهت تعیین اعتبار قرار میگیرد:
public interface ICookieValidatorService { Task ValidateAsync(CookieValidatePrincipalContext context); } public class CookieValidatorService : ICookieValidatorService { private readonly IUsersService _usersService; public CookieValidatorService(IUsersService usersService) { _usersService = usersService; _usersService.CheckArgumentIsNull(nameof(usersService)); } public async Task ValidateAsync(CookieValidatePrincipalContext context) { var userPrincipal = context.Principal; var claimsIdentity = context.Principal.Identity as ClaimsIdentity; if (claimsIdentity?.Claims == null || !claimsIdentity.Claims.Any()) { // this is not our issued cookie await handleUnauthorizedRequest(context); return; } var serialNumberClaim = claimsIdentity.FindFirst(ClaimTypes.SerialNumber); if (serialNumberClaim == null) { // this is not our issued cookie await handleUnauthorizedRequest(context); return; } var userIdString = claimsIdentity.FindFirst(ClaimTypes.UserData).Value; if (!int.TryParse(userIdString, out int userId)) { // this is not our issued cookie await handleUnauthorizedRequest(context); return; } var user = await _usersService.FindUserAsync(userId).ConfigureAwait(false); if (user == null || user.SerialNumber != serialNumberClaim.Value || !user.IsActive) { // user has changed his/her password/roles/stat/IsActive await handleUnauthorizedRequest(context); } await _usersService.UpdateUserLastActivityDateAsync(userId).ConfigureAwait(false); } private Task handleUnauthorizedRequest(CookieValidatePrincipalContext context) { context.RejectPrincipal(); return context.HttpContext.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme); } }
- آیا کوکی دریافت شده دارای اطلاعات HttpContext.User است؟
- آیا این کوکی به همراه اطلاعات فیلد SerialNumber است؟
- آیا این کوکی به همراه Id کاربر است؟
- آیا کاربری که بر اساس این Id یافت میشود غیرفعال شدهاست؟
- آیا کاربری که بر اساس این Id یافت میشود دارای SerialNumber یکسانی با نمونهی موجود در بانک اطلاعاتی است؟
اگر خیر، این اعتبارسنجی رد شده و بلافاصله کوکی کاربر نیز معدوم خواهد شد.
تنظیمات ابتدایی میانافزار اعتبارسنجی کاربران در ASP.NET Core 2.0
تنظیمات کامل ابتدایی میانافزار اعتبارسنجی کاربران در ASP.NET Core 2.0 را در فایل Startup.cs میتوانید مشاهده کنید.
ابتدا سرویسهای برنامه معرفی شدهاند:
public void ConfigureServices(IServiceCollection services) { services.AddScoped<IUnitOfWork, ApplicationDbContext>(); services.AddScoped<IUsersService, UsersService>(); services.AddScoped<IRolesService, RolesService>(); services.AddScoped<ISecurityService, SecurityService>(); services.AddScoped<ICookieValidatorService, CookieValidatorService>(); services.AddScoped<IDbInitializerService, DbInitializerService>();
سپس تنظیمات مرتبط با ترزیق وابستگیهای ApplicationDbContext برنامه انجام شدهاست. در اینجا رشتهی اتصالی، از فایل appsettings.json خوانده شده و سپس در اختیار متد UseSqlServer قرار میگیرد:
services.AddDbContext<ApplicationDbContext>(options => { options.UseSqlServer( Configuration.GetConnectionString("DefaultConnection"), serverDbContextOptionsBuilder => { var minutes = (int)TimeSpan.FromMinutes(3).TotalSeconds; serverDbContextOptionsBuilder.CommandTimeout(minutes); serverDbContextOptionsBuilder.EnableRetryOnFailure(); }); });
در ادامه تعدادی Policy مبتنی بر نقشهای ثابت سیستم را تعریف کردهایم. این کار اختیاری است اما روش توصیه شدهی در ASP.NET Core، کار با Policyها است تا کار مستقیم با نقشها. Policyها انعطاف پذیری بیشتری را نسبت به نقشها ارائه میدهند و در اینجا به سادگی میتوان چندین نقش و یا حتی Claim را با هم ترکیب کرد و به صورت یک Policy ارائه داد:
// Only needed for custom roles. services.AddAuthorization(options => { options.AddPolicy(CustomRoles.Admin, policy => policy.RequireRole(CustomRoles.Admin)); options.AddPolicy(CustomRoles.User, policy => policy.RequireRole(CustomRoles.User)); });
قسمت اصلی تنظیمات میان افزار اعتبارسنجی مبتنی بر کوکیها در اینجا قید شدهاست:
// Needed for cookie auth. services .AddAuthentication(options => { options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme; options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme; options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme; }) .AddCookie(options => { options.SlidingExpiration = false; options.LoginPath = "/api/account/login"; options.LogoutPath = "/api/account/logout"; //options.AccessDeniedPath = new PathString("/Home/Forbidden/"); options.Cookie.Name = ".my.app1.cookie"; options.Cookie.HttpOnly = true; options.Cookie.SecurePolicy = CookieSecurePolicy.SameAsRequest; options.Cookie.SameSite = SameSiteMode.Lax; options.Events = new CookieAuthenticationEvents { OnValidatePrincipal = context => { var cookieValidatorService = context.HttpContext.RequestServices.GetRequiredService<ICookieValidatorService>(); return cookieValidatorService.ValidateAsync(context); } }; });
کار نهایی تنظیمات میان افزار اعتبارسنجی در متد Configure با فراخوانی UseAuthentication صورت میگیرد. اینجا است که میان افزار، به برنامه معرفی خواهد شد:
public void Configure(IApplicationBuilder app, IHostingEnvironment env) { app.UseAuthentication();
همچنین پس از آن، کار اجرای سرویس آغاز بانک اطلاعاتی نیز انجام شدهاست تا نقشها و کاربر Admin را به سیستم اضافه کند:
var scopeFactory = app.ApplicationServices.GetRequiredService<IServiceScopeFactory>(); using (var scope = scopeFactory.CreateScope()) { var dbInitializer = scope.ServiceProvider.GetService<IDbInitializerService>(); dbInitializer.Initialize(); dbInitializer.SeedData(); }
پیاده سازی ورود و خروج به سیستم
پس از این مقدمات به مرحلهی آخر پیاده سازی این سیستم اعتبارسنجی میرسیم.
پیاده سازی Login
در اینجا از سرویس کاربران استفاده شده و بر اساس نام کاربری و کلمهی عبور ارسالی به سمت سرور، این کاربر یافت خواهد شد.
در صورت وجود این کاربر، مرحلهی نهایی کار، فراخوانی متد الحاقی HttpContext.SignInAsync است:
[AllowAnonymous] [HttpPost("[action]")] public async Task<IActionResult> Login([FromBody] User loginUser) { if (loginUser == null) { return BadRequest("user is not set."); } var user = await _usersService.FindUserAsync(loginUser.Username, loginUser.Password).ConfigureAwait(false); if (user == null || !user.IsActive) { await HttpContext.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme); return Unauthorized(); } var loginCookieExpirationDays = _configuration.GetValue<int>("LoginCookieExpirationDays", defaultValue: 30); var cookieClaims = await createCookieClaimsAsync(user).ConfigureAwait(false); await HttpContext.SignInAsync( CookieAuthenticationDefaults.AuthenticationScheme, cookieClaims, new AuthenticationProperties { IsPersistent = true, // "Remember Me" IssuedUtc = DateTimeOffset.UtcNow, ExpiresUtc = DateTimeOffset.UtcNow.AddDays(loginCookieExpirationDays) }); await _usersService.UpdateUserLastActivityDateAsync(user.Id).ConfigureAwait(false); return Ok(); }
private async Task<ClaimsPrincipal> createCookieClaimsAsync(User user) { var identity = new ClaimsIdentity(CookieAuthenticationDefaults.AuthenticationScheme); identity.AddClaim(new Claim(ClaimTypes.NameIdentifier, user.Id.ToString())); identity.AddClaim(new Claim(ClaimTypes.Name, user.Username)); identity.AddClaim(new Claim("DisplayName", user.DisplayName)); // to invalidate the cookie identity.AddClaim(new Claim(ClaimTypes.SerialNumber, user.SerialNumber)); // custom data identity.AddClaim(new Claim(ClaimTypes.UserData, user.Id.ToString())); // add roles var roles = await _rolesService.FindUserRolesAsync(user.Id).ConfigureAwait(false); foreach (var role in roles) { identity.AddClaim(new Claim(ClaimTypes.Role, role.Name)); } return new ClaimsPrincipal(identity); }
[Route("api/[controller]")] [Authorize(Policy = CustomRoles.Admin)] public class MyProtectedAdminApiController : Controller
پیاده سازی Logout
متد الحاقی HttpContext.SignOutAsync کار Logout کاربر را تکمیل میکند.
[AllowAnonymous] [HttpGet("[action]"), HttpPost("[action]")] public async Task<bool> Logout() { await HttpContext.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme); return true; }
آزمایش نهایی برنامه
در فایل index.html ، نمونهای از متدهای لاگین، خروج و فراخوانی اکشن متدهای محافظت شده را مشاهده میکنید. این روش برای برنامههای تک صفحهای وب یا SPA نیز میتواند مفید باشد و به همین نحو کار میکنند.
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید.
دوره بررسی ASP.NET CORE Identity
ASP.NET CORE Identity Under the Hood | Authentication & Authorization | .NET 8
00:00:00 Introduction
00:04:31 1. Security Overview
00:10:34 2. Authentication and Authorization Flow
00:17:18 3. ASP.NET Core Basics
00:23:31 4. Security Context in ASP.NET Core
00:27:23 5. Anonymous Identity
00:33:26 6. Create a Login Page with Razor Pages
00:46:02 7. Generate Cookie with Cookie Authentication Handler
01:06:01 8. Authenticaiton Middle and Authentication Scheme
01:15:16 9. Authorization Architecture Flow
01:23:58 10. Simple Policy based Authorization
01:43:50 11. Login & Logout Partial View
01:52:56 12. Custom Policy based Authorization
02:05:11 13. Cookie Lifespan & Browser Session
همچنین باید درنظر داشت، ASP.NET Core Identity یک سیستم اعتبارسنجی مبتنی بر کوکیها است. دقیقا زمانیکه کار AddIdentity را انجام میدهیم، در پشت صحنه همان services.AddAuthentication().AddCookie قسمت قبل فراخوانی میشود. بنابراین بکارگیری آن با JSON Web Tokens هرچند مشکلی را به همراه ندارد و میتوان یک سیستم اعتبارسنجی «دوگانه» را نیز در اینجا داشت، اما ... سربار اضافی تولید کوکیها را نیز به همراه دارد؛ هرچند برای کار با میانافزار اعتبارسنجی، الزامی به استفادهی از ASP.NET Core Identity نیست و عموما اگر از آن به همراه JWT استفاده میکنند، بیشتر به دنبال پیاده سازیهای پیشفرض مدیریت کاربران و نقشهای آن هستند و نه قسمت تولید کوکیهای آن. البته در مطلب جاری این موارد را نیز همانند مطلب اعتبارسنجی مبتنی بر کوکیها، خودمان مدیریت خواهیم کرد و در نهایت سیستم تهیه شده، هیچ نوع کوکی را تولید و یا مدیریت نمیکند.
تنظیمات آغازین برنامه جهت فعالسازی اعتبارسنجی مبتنی بر JSON Web Tokens
اولین تفاوت پیاده سازی یک سیستم اعتبارسنجی مبتنی بر JWT، با روش مبتنی بر کوکیها، تنظیمات متد ConfigureServices فایل آغازین برنامه است:
public void ConfigureServices(IServiceCollection services) { services.Configure<BearerTokensOptions>(options => Configuration.GetSection("BearerTokens").Bind(options)); services .AddAuthentication(options => { options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme; options.DefaultSignInScheme = JwtBearerDefaults.AuthenticationScheme; options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme; }) .AddJwtBearer(cfg => { cfg.RequireHttpsMetadata = false; cfg.SaveToken = true; cfg.TokenValidationParameters = new TokenValidationParameters { ValidIssuer = Configuration["BearerTokens:Issuer"], ValidAudience = Configuration["BearerTokens:Audience"], IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(Configuration["BearerTokens:Key"])), ValidateIssuerSigningKey = true, ValidateLifetime = true, ClockSkew = TimeSpan.Zero }; cfg.Events = new JwtBearerEvents { OnAuthenticationFailed = context => { var logger = context.HttpContext.RequestServices.GetRequiredService<ILoggerFactory>().CreateLogger(nameof(JwtBearerEvents)); logger.LogError("Authentication failed.", context.Exception); return Task.CompletedTask; }, OnTokenValidated = context => { var tokenValidatorService = context.HttpContext.RequestServices.GetRequiredService<ITokenValidatorService>(); return tokenValidatorService.ValidateAsync(context); }, OnMessageReceived = context => { return Task.CompletedTask; }, OnChallenge = context => { var logger = context.HttpContext.RequestServices.GetRequiredService<ILoggerFactory>().CreateLogger(nameof(JwtBearerEvents)); logger.LogError("OnChallenge error", context.Error, context.ErrorDescription); return Task.CompletedTask; } }; });
{ "BearerTokens": { "Key": "This is my shared key, not so secret, secret!", "Issuer": "http://localhost/", "Audience": "Any", "AccessTokenExpirationMinutes": 2, "RefreshTokenExpirationMinutes": 60 } }
سپس کار فراخوانی services.AddAuthentication صورت گرفتهاست. تفاوت این مورد با حالت اعتبارسنجی مبتنی بر کوکیها، ثوابتی است که با JwtBearerDefaults شروع میشوند. در حالت استفادهی از کوکیها، این ثوابت بر اساس CookieAuthenticationDefaults تنظیم خواهند شد.
البته میتوان متد AddAuthentication را بدون هیچگونه پارامتری نیز فراخوانی کرد. این حالت برای اعتبارسنجیهای دوگانه مفید است. برای مثال زمانیکه پس از AddAuthentication هم AddJwtBearer را ذکر کردهاید و هم AddCookie اضافه شدهاست. اگر چنین کاری را انجام دادید، اینبار باید درحین تعریف فیلتر Authorize، دقیقا مشخص کنید که حالت مبتنی بر JWT مدنظر شما است، یا حالت مبتنی بر کوکیها:
[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]
بررسی تنظیمات متد AddJwtBearer
در کدهای فوق، تنظیمات متد AddJwtBearer یک چنین مفاهیمی را به همراه دارند:
- تنظیم SaveToken به true، به این معنا است که میتوان به توکن دریافتی از سمت کاربر، توسط متد HttpContext.GetTokenAsync در کنترلرهای برنامه دسترسی یافت.
در قسمت تنظیمات TokenValidationParameters آن:
- کار خواندن فایل appsettings.json برنامه جهت تنظیم صادر کننده و مخاطبین توکن انجام میشود. سپس IssuerSigningKey به یک کلید رمزنگاری متقارن تنظیم خواهد شد. این کلید نیز در تنظیمات برنامه قید میشود.
- تنظیم ValidateIssuerSigningKey به true سبب خواهد شد تا میانافزار اعتبارسنجی، بررسی کند که آیا توکن دریافتی از سمت کاربر توسط برنامهی ما امضاء شدهاست یا خیر؟
- تنظیم ValidateLifetime به معنای بررسی خودکار طول عمر توکن دریافتی از سمت کاربر است. اگر توکن منقضی شده باشد، اعتبارسنجی به صورت خودکار خاتمه خواهد یافت.
- ClockSkew به معنای تنظیم یک تلرانس و حد تحمل مدت زمان منقضی شدن توکن در حالت ValidateLifetime است. در اینجا به صفر تنظیم شدهاست.
سپس به قسمت JwtBearerEvents میرسیم:
- OnAuthenticationFailed زمانی فراخوانی میشود که اعتبارسنجهای تنظیمی فوق، با شکست مواجه شوند. برای مثال طول عمر توکن منقضی شده باشد و یا توسط ما امضاء نشدهباشد. در اینجا میتوان به این خطاها دسترسی یافت و درصورت نیاز آنها را لاگ کرد.
- OnChallenge نیز یک سری دیگر از خطاهای اعتبارسنجی را پیش از ارسال آنها به فراخوان در اختیار ما قرار میدهد.
- OnMessageReceived برای حالتی است که توکن دریافتی، توسط هدر مخصوص Bearer به سمت سرور ارسال نمیشود. عموما هدر ارسالی به سمت سرور یک چنین شکلی را دارد:
$.ajax({ headers: { 'Authorization': 'Bearer ' + jwtToken },
const string tokenKey = "my.custom.jwt.token.key"; if (context.HttpContext.Items.ContainsKey(tokenKey)) { context.Token = (string)context.HttpContext.Items[tokenKey]; }
تهیه یک اعتبارسنج توکن سفارشی
قسمت OnTokenValidated تنظیمات ابتدای برنامه به این صورت مقدار دهی شدهاست:
OnTokenValidated = context => { var tokenValidatorService = context.HttpContext.RequestServices.GetRequiredService<ITokenValidatorService>(); return tokenValidatorService.ValidateAsync(context); },
public class TokenValidatorService : ITokenValidatorService { private readonly IUsersService _usersService; private readonly ITokenStoreService _tokenStoreService; public TokenValidatorService(IUsersService usersService, ITokenStoreService tokenStoreService) { _usersService = usersService; _usersService.CheckArgumentIsNull(nameof(usersService)); _tokenStoreService = tokenStoreService; _tokenStoreService.CheckArgumentIsNull(nameof(_tokenStoreService)); } public async Task ValidateAsync(TokenValidatedContext context) { var userPrincipal = context.Principal; var claimsIdentity = context.Principal.Identity as ClaimsIdentity; if (claimsIdentity?.Claims == null || !claimsIdentity.Claims.Any()) { context.Fail("This is not our issued token. It has no claims."); return; } var serialNumberClaim = claimsIdentity.FindFirst(ClaimTypes.SerialNumber); if (serialNumberClaim == null) { context.Fail("This is not our issued token. It has no serial."); return; } var userIdString = claimsIdentity.FindFirst(ClaimTypes.UserData).Value; if (!int.TryParse(userIdString, out int userId)) { context.Fail("This is not our issued token. It has no user-id."); return; } var user = await _usersService.FindUserAsync(userId).ConfigureAwait(false); if (user == null || user.SerialNumber != serialNumberClaim.Value || !user.IsActive) { // user has changed his/her password/roles/stat/IsActive context.Fail("This token is expired. Please login again."); } var accessToken = context.SecurityToken as JwtSecurityToken; if (accessToken == null || string.IsNullOrWhiteSpace(accessToken.RawData) || !await _tokenStoreService.IsValidTokenAsync(accessToken.RawData, userId).ConfigureAwait(false)) { context.Fail("This token is not in our database."); return; } await _usersService.UpdateUserLastActivityDateAsync(userId).ConfigureAwait(false); } }
- آیا توکن دریافتی به همراه Claims تنظیم شدهی درحین لاگین هست یا خیر؟
- آیا توکن دریافتی دارای یک Claim سفارشی به نام SerialNumber است؟ این SerialNumber معادل چنین فیلدی در جدول کاربران است.
- آیا توکن دریافتی دارای user-id است؟
- آیا کاربر یافت شدهی بر اساس این user-id هنوز فعال است و یا اطلاعات او تغییر نکردهاست؟
- همچنین در آخر کار بررسی میکنیم که آیا اصل توکن دریافتی، در بانک اطلاعاتی ما پیشتر ثبت شدهاست یا خیر؟
اگر خیر، بلافاصله متد context.Fail فراخوانی شده و کار اعتبارسنجی را با اعلام شکست آن، به پایان میرسانیم.
در قسمت آخر، نیاز است اطلاعات توکنهای صادر شده را ذخیره کنیم. به همین جهت نسبت به مطلب قبلی، جدول UserToken ذیل به برنامه اضافه شدهاست:
public class UserToken { public int Id { get; set; } public string AccessTokenHash { get; set; } public DateTimeOffset AccessTokenExpiresDateTime { get; set; } public string RefreshTokenIdHash { get; set; } public DateTimeOffset RefreshTokenExpiresDateTime { get; set; } public int UserId { get; set; } // one-to-one association public virtual User User { get; set; } }
از اطلاعات آن در دو قسمت TokenValidatorService فوق و همچنین قسمت logout برنامه استفاده میکنیم. در سیستم JWT، مفهوم logout سمت سرور وجود خارجی ندارد. اما با ذخیره سازی هش توکنها در بانک اطلاعاتی میتوان لیستی از توکنهای صادر شدهی توسط برنامه را تدارک دید. سپس در حین logout فقط کافی است tokenهای یک کاربر را حذف کرد. همینقدر سبب خواهد شد تا قسمت آخر TokenValidatorService با شکست مواجه شود؛ چون توکن ارسالی به سمت سرور دیگر در بانک اطلاعاتی وجود ندارد.
سرویس TokenStore
public interface ITokenStoreService { Task AddUserTokenAsync(UserToken userToken); Task AddUserTokenAsync( User user, string refreshToken, string accessToken, DateTimeOffset refreshTokenExpiresDateTime, DateTimeOffset accessTokenExpiresDateTime); Task<bool> IsValidTokenAsync(string accessToken, int userId); Task DeleteExpiredTokensAsync(); Task<UserToken> FindTokenAsync(string refreshToken); Task DeleteTokenAsync(string refreshToken); Task InvalidateUserTokensAsync(int userId); Task<(string accessToken, string refreshToken)> CreateJwtTokens(User user); }
پیاده سازی کامل این سرویس را در اینجا میتوانید مشاهده کنید.
تولید Access Tokens و Refresh Tokens
پس از تنظیمات ابتدایی برنامه، اکنون میتوانیم دو نوع توکن را تولید کنیم:
تولید Access Tokens
private async Task<string> createAccessTokenAsync(User user, DateTime expires) { var claims = new List<Claim> { // Unique Id for all Jwt tokes new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString()), // Issuer new Claim(JwtRegisteredClaimNames.Iss, _configuration.Value.Issuer), // Issued at new Claim(JwtRegisteredClaimNames.Iat, DateTime.UtcNow.ToUnixEpochDate().ToString(), ClaimValueTypes.Integer64), new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()), new Claim(ClaimTypes.Name, user.Username), new Claim("DisplayName", user.DisplayName), // to invalidate the cookie new Claim(ClaimTypes.SerialNumber, user.SerialNumber), // custom data new Claim(ClaimTypes.UserData, user.Id.ToString()) }; // add roles var roles = await _rolesService.FindUserRolesAsync(user.Id).ConfigureAwait(false); foreach (var role in roles) { claims.Add(new Claim(ClaimTypes.Role, role.Name)); } var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(_configuration.Value.Key)); var creds = new SigningCredentials(key, SecurityAlgorithms.HmacSha256); var token = new JwtSecurityToken( issuer: _configuration.Value.Issuer, audience: _configuration.Value.Audience, claims: claims, notBefore: DateTime.UtcNow, expires: expires, signingCredentials: creds); return new JwtSecurityTokenHandler().WriteToken(token); }
<ItemGroup> <PackageReference Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="2.0.0" /> </ItemGroup>
پس از تهیهی Claims، اینبار بجای یک کوکی، یک JSON Web Toekn را توسط متد new JwtSecurityTokenHandler().WriteToken تهیه خواهیم کرد. این توکن حاوی Claims، به همراه اطلاعات طول عمر و امضای مرتبطی است.
حاصل آن نیز یک رشتهاست که دقیقا به همین فرمت به سمت کلاینت ارسال خواهد شد. البته ما در اینجا دو نوع توکن را به سمت کلاینت ارسال میکنیم:
public async Task<(string accessToken, string refreshToken)> CreateJwtTokens(User user) { var now = DateTimeOffset.UtcNow; var accessTokenExpiresDateTime = now.AddMinutes(_configuration.Value.AccessTokenExpirationMinutes); var refreshTokenExpiresDateTime = now.AddMinutes(_configuration.Value.RefreshTokenExpirationMinutes); var accessToken = await createAccessTokenAsync(user, accessTokenExpiresDateTime.UtcDateTime).ConfigureAwait(false); var refreshToken = Guid.NewGuid().ToString().Replace("-", ""); await AddUserTokenAsync(user, refreshToken, accessToken, refreshTokenExpiresDateTime, accessTokenExpiresDateTime).ConfigureAwait(false); await _uow.SaveChangesAsync().ConfigureAwait(false); return (accessToken, refreshToken); }
جهت بالا رفتن امنیت سیستم، این Guid را هش کرد و سپس این هش را در بانک اطلاعاتی ذخیره میکنیم. به این ترتیب دسترسی غیرمجاز به این هشها، امکان بازیابی توکنهای اصلی را غیرممکن میکند.
پیاده سازی Login
پس از پیاده سازی متد CreateJwtTokens، کار ورود به سیستم به سادگی ذیل خواهد بود:
[AllowAnonymous] [HttpPost("[action]")] public async Task<IActionResult> Login([FromBody] User loginUser) { if (loginUser == null) { return BadRequest("user is not set."); } var user = await _usersService.FindUserAsync(loginUser.Username, loginUser.Password).ConfigureAwait(false); if (user == null || !user.IsActive) { return Unauthorized(); } var (accessToken, refreshToken) = await _tokenStoreService.CreateJwtTokens(user).ConfigureAwait(false); return Ok(new { access_token = accessToken, refresh_token = refreshToken }); }
پیاده سازی Refresh Token
پیاده سازی توکن به روز رسانی همانند عملیات لاگین است:
[AllowAnonymous] [HttpPost("[action]")] public async Task<IActionResult> RefreshToken([FromBody]JToken jsonBody) { var refreshToken = jsonBody.Value<string>("refreshToken"); if (string.IsNullOrWhiteSpace(refreshToken)) { return BadRequest("refreshToken is not set."); } var token = await _tokenStoreService.FindTokenAsync(refreshToken); if (token == null) { return Unauthorized(); } var (accessToken, newRefreshToken) = await _tokenStoreService.CreateJwtTokens(token.User).ConfigureAwait(false); return Ok(new { access_token = accessToken, refresh_token = newRefreshToken }); }
پیاده سازی Logout
در سیستمهای مبتنی بر JWT، پیاده سازی Logout سمت سرور بیمفهوم است؛ از این جهت که تا زمان انقضای یک توکن میتوان از آن توکن جهت ورود به سیستم و دسترسی به منابع آن استفاده کرد. بنابراین تنها راه پیاده سازی Logout، ذخیره سازی توکنها در بانک اطلاعاتی و سپس حذف آنها در حین خروج از سیستم است. به این ترتیب اعتبارسنج سفارشی توکنها، از استفادهی مجدد از توکنی که هنوز هم معتبر است و منقضی نشدهاست، جلوگیری خواهد کرد:
[AllowAnonymous] [HttpGet("[action]"), HttpPost("[action]")] public async Task<bool> Logout() { var claimsIdentity = this.User.Identity as ClaimsIdentity; var userIdValue = claimsIdentity.FindFirst(ClaimTypes.UserData)?.Value; // The Jwt implementation does not support "revoke OAuth token" (logout) by design. // Delete the user's tokens from the database (revoke its bearer token) if (!string.IsNullOrWhiteSpace(userIdValue) && int.TryParse(userIdValue, out int userId)) { await _tokenStoreService.InvalidateUserTokensAsync(userId).ConfigureAwait(false); } await _tokenStoreService.DeleteExpiredTokensAsync().ConfigureAwait(false); await _uow.SaveChangesAsync().ConfigureAwait(false); return true; }
آزمایش نهایی برنامه
در فایل index.html، نمونهای از متدهای لاگین، خروج و فراخوانی اکشن متدهای محافظت شده را مشاهده میکنید. این روش برای برنامههای تک صفحهای وب یا SPA نیز میتواند مفید باشد و به همین نحو کار میکنند.
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید.
IdentityServer4 v2 منتشر شد
Wow – this was probably our biggest update ever! Version 2.0 of IdentityServer4 is not only incorporating all the feedback we got over the last year, it also includes the necessary updates for ASP.NET Core 2 – and also has a couple of brand new features. See the release notes for a complete list as well as links to issues and PRs.
Endpoint xyz contains authorization metadata, but a middleware was not found that supports authorization. Configure your application startup by adding app.UseAuthorization() inside the call to Configure(..) in the application startup code.
محل صحیح تعریف میانافزار Authorization در ASP.NET Core 3.0
توصیه شدهاست میانافزار جدید Authorization، با فراخوانی متد UseAuthorization، بلافاصله پس از فراخوانی متد UseAuthentication معرفی شود. در این حالت این میانافزار، با یک Policy پیشفرض تنظیم میشود که قابل تغییر و بازنویسی است:
public void Configure(IApplicationBuilder app) { ... app.UseRouting(); app.UseAuthentication(); app.UseAuthorization(); app.UseEndpoints(endpoints => { endpoints.MapDefaultControllerRoute(); }); }
در ASP.NET Core 3.0، پس از تنظیمات فوق است که قطعه کد زیر و اعمال فیلتر Authorize، مجددا کار میکند:
public class HomeController : ControllerBase { [Authorize] public IActionResult BuyWidgets() { ... } }
میتوان AuthorizeFilter را به صورت یک فیلتر سراسری (global filter in MVC) تعریف کرد تا به تمام کنترلرها و اکشن متدها اعمال شود. هرچند این روش هنوز هم در ASP.NET Core 3.0 کار میکند، اما روش توصیه شدهی جدید آن به صورت زیر است:
public void Configure(IApplicationBuilder app) { ... app.UseRouting(); app.UseAuthentication(); app.UseAuthorization(); app.UseEndpoints(endpoints => { endpoints.MapDefaultControllerRoute().RequireAuthorization(); }); }
[AllowAnonymous] public class HomeController : ControllerBase { ... }
سفارشی سازی سیاستهای Authorization در ASP.NET Core 3.0
اگر بخواهیم DefaultPolicy میانافزار Authorization را بازنویسی کنیم، میتوان از متد services.AddAuthorization به صورت زیر استفاده کرد که در آن authentication و داشتن یک Scope خاص را اجباری میکند:
public void ConfigureServices(IServiceCollection services) { ... services.AddAuthorization(options => { options.DefaultPolicy = new AuthorizationPolicyBuilder() .RequireAuthenticatedUser() .RequireScope("MyScope") .Build(); }); }
با تنظیم FallbackPolicy، میتوان تمام endpointهایی را که توسط فیلتر [Authorize] و یا ()RequireAuthorization محافظت نشدهاند، محافظت کرد.
DefaultPolicy توسط فیلتر [Authorize] و یا ()RequireAuthorization مورد استفاده قرار میگیرد؛ اما FallbackPolicy زمانی بکار خواهد رفت که هیچ نوع سیاست دسترسی تنظیم نشدهباشد. حالت پیشفرض FallbackPolicy، پذیرش تمام درخواستها بدون اعتبارسنجی است.
کارکرد مثال زیر با مثالهای قبلی که از DefaultPolicy استفاده میکردند، یکی است و هدف آن، اجبار به اعتبارسنجی کاربران در همهجا (تمام endpoints)، منهای مواردی است که از فیلتر AllowAnonymous استفاده میشود:
public void ConfigureServices(IServiceCollection services) { services.AddAuthorization(options => { options.FallbackPolicy = new AuthorizationPolicyBuilder() .RequireAuthenticatedUser() .RequireScope("MyScope") .Build(); }); } public void Configure(IApplicationBuilder app) { app.UseRouting(); app.UseAuthentication(); app.UseAuthorization(); app.UseEndpoints(endpoints => { endpoints.MapDefaultControllerRoute(); }); } [AllowAnonymous] public class HomeController : ControllerBase { }
امکان اعمال سفارشی میانافزار Authorization به Endpointهای مجزا
برای مثال در مبحث «بررسی سلامت برنامه»، فریمورک، اعتبارسنجی درخواستهای آنرا پیش بینی نکردهاست؛ اما اینبار میتوان اعتبارسنجی را به endpoint آن اعمال کرد:
public void Configure(IApplicationBuilder app) { ... app.UseRouting(); app.UseAuthentication(); app.UseAuthorization(); app.UseEndpoints(endpoints => { endpoints .MapHealthChecks("/healthz") .RequireAuthorization(new AuthorizeAttribute(){ Roles = "admin", }); }); }
اعمال کنترل دسترسی پویا در پروژههای ASP.NET Core با استفاده از AuthorizationPolicyProvider سفارشی
در مطلب «سفارشی سازی ASP.NET Core Identity - قسمت پنجم - سیاستهای دسترسی پویا» به طور مفصل به قضیه کنترل دسترسی پویا در ASP.NET Core Identity پرداخته شدهاست؛ در این مطلب روش دیگری را بررسی خواهیم کرد.
مشخص میباشد که بدون وابستگی به روش خاصی، خیلی ساده میتوان به شکل زیر عمل کرد:
services.AddAuthorization(options => { options.AddPolicy("View Projects", policy => policy.RequireClaim(CustomClaimTypes.Permission, "projects.view")); });
[Authorize("View Projects")] public IActionResult Index(int siteId) { return View(); }
Using a large range of policies (for different room numbers or ages, for example), so it doesn’t make sense to add each individual authorization policy with an AuthorizationOptions.AddPolicy call.
کار با پیاده سازی واسط IAuthorizationPolicyProvider شروع میشود؛ یا شاید ارث بری از DefaultAuthorizationPolicyProvider رجیستر شدهی در سیستم DI و توسعه آن هم کافی باشد.
public class AuthorizationPolicyProvider : DefaultAuthorizationPolicyProvider { public AuthorizationPolicyProvider(IOptions<AuthorizationOptions> options) : base(options) { } public override Task<AuthorizationPolicy> GetPolicyAsync(string policyName) { if (!policyName.StartsWith(PermissionAuthorizeAttribute.PolicyPrefix, StringComparison.OrdinalIgnoreCase)) { return base.GetPolicyAsync(policyName); } var permissionNames = policyName.Substring(PermissionAuthorizeAttribute.PolicyPrefix.Length).Split(','); var policy = new AuthorizationPolicyBuilder() .RequireClaim(CustomClaimTypes.Permission, permissionNames) .Build(); return Task.FromResult(policy); } }
متد GetPolicyAsync موظف به یافتن و بازگشت یک Policy ثبت شده میباشد؛ با این حال میتوان با بازنویسی آن و با استفاده از وهلهای از AuthorizationPolicyBuilder، فرآیند تعریف سیاست درخواست شده را که احتمالا در تنظیمات آغازین پروژه تعریف نشده و پیشوند مدنظر را نیز دارد، خوکار کرد. در اینجا امکان ترکیب کردن چندین دسترسی را هم خواهیم داشت که برای این منظور میتوان دسترسیهای مختلف را به صورت comma separated به سیستم معرفی کرد.
نکتهی مهم در تکه کد بالا مربوط است به PolicyPrefix که با استفاده از آن مشخص کردهایم که برای هر سیاست درخواستی، این فرآیند را طی نکند و موجب اختلال در سیستم نشود.
پس از پیاده سازی واسط مطرح شده، لازم است این پیاده سازی جدید را به سیستم DI هم معرفی کنید:
services.AddSingleton<IAuthorizationPolicyProvider, AuthorizationPolicyProvider>();
خوب، تا اینجا فرآیند تعریف سیاستها به صورت خودکار انجام شد. در ادامه نیاز است با تعریف یک فیلتر Authorization، بتوان لیست دسترسیهای مورد نظر برای اکشنی خاص را نیز مشخص کرد تا در متد GetPolicyAsync فوق، کار ثبت خودکار سیاست دسترسی متناظر با آنرا توسط فراخوانی متد policyBuilder.RequireClaim، انجام دهد تا دیگر نیازی به تعریف دستی و جداگانهی آن، در کلاس آغازین برنامه نباشد. برای این منظور به شکل زیر عمل خواهیم کرد:
public class PermissionAuthorizeAttribute : AuthorizeAttribute { internal const string PolicyPrefix = "PERMISSION:"; /// <summary> /// Creates a new instance of <see cref="AuthorizeAttribute"/> class. /// </summary> /// <param name="permissions">A list of permissions to authorize</param> public PermissionAuthorizeAttribute(params string[] permissions) { Policy = $"{PolicyPrefix}{string.Join(",", permissions)}"; } }
همانطور که مشخص میباشد، رشته PERMISSION به عنوان پیشوند رشته تولیدی از لیست اسامی دسترسیها، استفاده شدهاست و در پراپرتی Policy قرار داده شدهاست. این بار برای کنترل دسترسی میتوان به شکل زیر عمل کرد:
[PermissionAuthorize(PermissionNames.Projects_View)] public IActionResult Get(FilteredQueryModel query) { //... } [PermissionAuthorize(PermissionNames.Projects_Create)] public IActionResult Post(ProjectModel model) { //... }
برای مثال در اولین فراخوانی فیلتر PermissionAuthorize فوق، مقدار ثابت PermissionNames.Projects_View به عنوان یک Policy جدید به متد GetPolicyAsync کلاس AuthorizationPolicyProvider سفارشی ما ارسال میشود. چون دارای پیشوند «:PERMISSION» است، مورد پردازش قرار گرفته و توسط متد policyBuilder.RequireClaim به صورت خودکار به سیستم معرفی و ثبت خواهد شد.
همچنین راه حل مطرح شده برای مدیریت دسترسیهای پویا، در gist به اشتراک گذاشته شده «موجودیتهای مرتبط با مدیریت دسترسیهای پویا» را نیز مد نظر قرار دهید.
پیشنیازهای اجرای پروژهی DNT Identity
- ابتدا نیاز است حداقل ASP.NET Core Identity 1.1 را نصب کرده باشید.
- همچنین بانک اطلاعاتی پایهی آن که به صورت خودکار در اولین بار اجرای برنامه تشکیل میشود، مبتنی بر LocalDB است. بنابراین اگر قصد تغییری را در تنظیمات Context آن ندارید، بهتر است LocalDB را نیز بر روی سیستم نصب کنید. هرچند با تغییر تنظیم ActiveDatabase به SqlServer در فایل appsettings.json، برنامه به صورت خودکار از نگارش کامل SqlServer استفاده خواهد کرد. رشتهی اتصالی آن نیز در مدخل ConnectionStrings فایل appsettings.json ذکر شدهاست و قابل تغییر است. برای شروع به کار، نیازی به اجرای مراحل Migrations را نیز ندارید و همینقدر که برنامه را اجرا کنید، بانک اطلاعاتی آن نیز تشکیل خواهد شد.
- کاربر پیش فرض Admin سیستم و کلمهی عبور آن از مدخل AdminUserSeed فایل appsettings.json خوانده میشوند.
- تنظیمات ایمیل پیش فرض برنامه به استفادهی از PickupFolder در مدخل Smtp فایل appsettings.json تنظیم شدهاست. بنابراین تمام ایمیلهای برنامه را جهت آزمایش محلی میتوانید در مسیر PickupFolder آن یا همان c:\smtppickup مشاهده کنید. محتوای این ایمیلها را نیز توسط مرورگر (drag&drop بر روی یک tab جدید) و یا برنامهی Outlook میتوان مشاهده کرد.
سفارشی سازی کلید اصلی موجودیتهای ASP.NET Core Identity
ASP.NET Core Identity به همراه دو سری موجودیت است. یک سری سادهی آن که از یک string به عنوان نوع کلید اصلی استفاده میکنند و سری دوم، حالت جنریک که در آن میتوان نوع کلید اصلی را به صورت صریحی قید کرد و تغییر داد. در اینجا نیز قصد داریم از حالت جنریک استفاده کرده و نوع کلید اصلی جداول را تغییر دهیم. تمام این موجودیتهای تغییر یافته را در پوشهی src\ASPNETCoreIdentitySample.Entities\Identity نیز میتوانید مشاهده کنید و شامل موارد ذیل هستند:
جدول نقشهای سیستم
public class Role : IdentityRole<int, UserRole, RoleClaim>, IAuditableEntity { public Role() { } public Role(string name) : this() { Name = name; } public Role(string name, string description) : this(name) { Description = description; } public string Description { get; set; } }
در اولین بار اجرای برنامه، نقش Admin در این جدول ثبت خواهد شد.
جدول کاربران منتسب به نقشها
public class UserRole : IdentityUserRole<int>, IAuditableEntity { public virtual User User { get; set; } public virtual Role Role { get; set; } }
در اولین بار اجرای برنامه، کاربر شماره 1 یا همان Admin به نقش شماره 1 یا همان Admin، انتساب داده میشود.
جدول جدید IdentityRoleClaim سیستم
public class RoleClaim : IdentityRoleClaim<int>, IAuditableEntity { public virtual Role Role { get; set; } }
جدول UserClaim سیستم
public class UserClaim : IdentityUserClaim<int>, IAuditableEntity { public virtual User User { get; set; } }
جداول توکن و لاگینهای کاربران
public class UserToken : IdentityUserToken<int>, IAuditableEntity { public virtual User User { get; set; } } public class UserLogin : IdentityUserLogin<int>, IAuditableEntity { public virtual User User { get; set; } }
جدول کاربران سیستم
public class User : IdentityUser<int, UserClaim, UserRole, UserLogin>, IAuditableEntity { public User() { UserUsedPasswords = new HashSet<UserUsedPassword>(); UserTokens = new HashSet<UserToken>(); } [StringLength(450)] public string FirstName { get; set; } [StringLength(450)] public string LastName { get; set; } [NotMapped] public string DisplayName { get { var displayName = $"{FirstName} {LastName}"; return string.IsNullOrWhiteSpace(displayName) ? UserName : displayName; } } [StringLength(450)] public string PhotoFileName { get; set; } public DateTimeOffset? BirthDate { get; set; } public DateTimeOffset? CreatedDateTime { get; set; } public DateTimeOffset? LastVisitDateTime { get; set; } public bool IsEmailPublic { get; set; } public string Location { set; get; } public bool IsActive { get; set; } = true; public virtual ICollection<UserUsedPassword> UserUsedPasswords { get; set; } public virtual ICollection<UserToken> UserTokens { get; set; } } public class UserUsedPassword : IAuditableEntity { public int Id { get; set; } public string HashedPassword { get; set; } public virtual User User { get; set; } public int UserId { get; set; } }
فیلد IsActive نیز از این جهت اضافه شدهاست تا بجای حذف فیزیکی یک کاربر، بتوان اکانت او را غیرفعال کرد.
تعریف Shadow properties ثبت تغییرات رکوردها
در #C ارثبری چندگانهی کلاسها ممنوع است؛ مگر اینکه از اینترفیسها استفاده شود. برای مثال IdentityUser یک کلاس است و در اینجا دیگر نمیتوان کلاس دومی را به نام BaseEntity جهت اعمال خواص اضافهتری اعمال کرد. به همین جهت است که اعمال اینترفیس خالی IAuditableEntity را در اینجا مشاهده میکنید. این اینترفیس کار علامتگذاری کلاسهایی را انجام میدهد که قصد داریم به آنها به صورت خودکار، خواصی مانند تاریخ ثبت رکورد، تاریخ ویرایش آن و غیره را اعمال کنیم.
در Context برنامه، به اطلاعات src\ASPNETCoreIdentitySample.Entities\AuditableEntity مراجعه شده و متد AddAuditableShadowProperties بر روی تمام کلاسهایی از نوع IAuditableEntity اعمال میشود. این متد خواص مدنظر ما را مانند ModifiedDateTime به صورت Shadow properties به موجودیتهای علامتگذاری شده اضافه میکند.
همچنین متد SetAuditableEntityPropertyValues، کار مقدار دهی خودکار این خواص را انجام خواهد داد. بنابراین دیگر نیازی نیست در برنامه برای مثال IP شخص ثبت کننده یا ویرایش کننده را به صورت دستی مقدار دهی کرد. هم تعریف و هم مقدار دهی آن توسط Change tracker سیستم به صورت خودکار انجام خواهند شد.
تاثیر افزودن Shadow properties را بر روی کلاس نقشهای سیستم، در تصویر فوق ملاحظه میکنید. خواصی که به صورت معمول در کلاسهای برنامه ظاهر نمیشوند و صرفا هدف بازبینی سیستم را برآورده میکنند و مدیریت آنها نیز در اینجا کاملا خودکار است.
سفارشی سازی DbContext برنامه
نحوهی سفارشی سازی DbContext برنامه را در پوشهی src\ASPNETCoreIdentitySample.DataLayer\Context و src\ASPNETCoreIdentitySample.DataLayer\Mappings ملاحظه میکنید. پوشهی Context حاوی کلاس ApplicationDbContextBase است که تمام سفارشی سازیهای لازم بر روی آن انجام شدهاست؛ شامل:
- تغییر نوع کلید اصلی موجودیتها به همراه معرفی موجودیتهای تغییر یافته:
public abstract class ApplicationDbContextBase : IdentityDbContext<User, Role, int, UserClaim, UserRole, UserLogin, RoleClaim, UserToken>, IUnitOfWork
- اعمال متد BeforeSaveTriggers به تمام نگارشهای مختلف SaveChanges
protected void BeforeSaveTriggers() { ValidateEntities(); SetShadowProperties(); this.ApplyCorrectYeKe(); }
- انتخاب نوع بانک اطلاعاتی مورد استفاده در متد OnConfiguring
در اینجا است که خاصیت ActiveDatabase تنظیم شدهی در فایل appsettings.json خوانده شده و اعمال میشوند. تعریف متد GetDbConnectionString را در کلاس SiteSettingsExtesnsions مشاهده میکنید. کار آن استفادهی از بانک اطلاعاتی درون حافظهای، جهت انجام آزمونهای واحد و یا استفادهی از LocalDb و یا نگارش کامل SQL Server میباشد. اگر علاقمند بودید تا بانک اطلاعاتی دیگری (مثلا SQLite) را نیز اضافه کنید، ابتدا enum ایی به نام ActiveDatabase را تغییر داده و سپس متد GetDbConnectionString و متد OnConfiguring را جهت درج اطلاعات این بانک اطلاعاتی جدید، اصلاح کنید.
پس از تعریف این DbContext پایهی سفارشی سازی شده، کلاس جدید ApplicationDbContext را مشاهده میکنید. این کلاس Context ایی است که در برنامه از آن استفاده میشود و از کلاس پایه ApplicationDbContextBase مشتق شدهاست:
public class ApplicationDbContext : ApplicationDbContextBase
تنظیمات mapping آنها نیز به متد OnModelCreating این کلاس اضافه خواهند شد. فقط نحوهی استفادهی از آن را بهخاطر داشته باشید:
protected override void OnModelCreating(ModelBuilder builder) { // it should be placed here, otherwise it will rewrite the following settings! base.OnModelCreating(builder); // Adds all of the ASP.NET Core Identity related mappings at once. builder.AddCustomIdentityMappings(SiteSettings.Value); // Custom application mappings // This should be placed here, at the end. builder.AddAuditableShadowProperties(); }
سپس متد AddCustomIdentityMappings ذکر شدهاست. این متد اطلاعات src\ASPNETCoreIdentitySample.DataLayer\Mappings را به صورت خودکار و یکجا اضافه میکند که در آن برای مثال نام جداول پیش فرض Identity سفارشی سازی شدهاند.
در آخر باید AddAuditableShadowProperties فراخوانی شود تا خواص سایهای که پیشتر در مورد آنها بحث شد، به سیستم به صورت خودکار اضافه شوند.
تمام نگاشتهای سفارشی شما باید در این میان و در قسمت «Custom application mappings» درج شوند.
در قسمت بعدی، نحوهی سفارشی سازی سرویسهای پایهی Identity را بررسی خواهیم کرد. بدون این سفارشی سازی و اطلاعات رسانی به سرویسهای پایه که از چه موجودیتهای جدید سفارشی سازی شدهایی در حال استفاده هستیم، کار Migrations انجام نخواهد شد.
کدهای کامل این سری را در مخزن کد DNT Identity میتوانید ملاحظه کنید.
در این بین اگر به قالب پیشفرض پروژههای MVC تولید شدهی توسط ASP.NET Core 2.1 نیز دقت کنید، پشتیبانی توکار از پیشنیازهای GDPR در آن لحاظ شدهاست؛ چه از لحاظ گوشزد کردن شرایط حریم خصوصی و پذیرش آن و چه از لحاظ «پاک کردن» و «پس گرفتن» اطلاعات شخصی.
قالب و کوکی پذیرش شرایط حریم خصوصی سایت (Cookie Consent)
اگر قالب پیشفرض یک پروژهی ASP.NET Core 2.1 را اجرا کنید، تصویر فوق را که در آن نوار پذیرش شرایط حریم خصوصی سایت در بالای صفحه درج شدهاست، مشاهده خواهید کرد.
قالب جدید نوار پذیرش شرایط حریم خصوصی در مسیر Views\Shared\_CookieConsentPartial.cshtml واقع شدهاست و در فایل layout برنامه توسط tag helper جدید Partial، رندر و نمایش داده میشود:
<partial name="_CookieConsentPartial" />
@using Microsoft.AspNetCore.Http.Features @{ var consentFeature = Context.Features.Get<ITrackingConsentFeature>(); var showBanner = !consentFeature?.CanTrack ?? false; var cookieString = consentFeature?.CreateConsentCookie(); }
الف) تنظیم نیاز به دریافت پذیرش
public void ConfigureServices(IServiceCollection services) { services.Configure<CookiePolicyOptions>(options => { // This lambda determines whether user consent for non-essential cookies is needed for a given request. options.CheckConsentNeeded = context => true; options.MinimumSameSitePolicy = SameSiteMode.None; });
public void Configure(IApplicationBuilder app, IHostingEnvironment env) { // ... app.UseCookiePolicy();
علاوه بر Cookie Consent فوق که در یک قالب ابتدایی MVC نیز درج شدهاست، در قالب پروژههای ASP.NET Core Identity، دو گزینهی جدید دریافت اطلاعات شخصی و همچنین حذف اکانت (دادن حق فراموشی به کاربران) نیز پیشبینی شدهاست: PersonalData.cshtml
البته این صفحه جزو بستهی جدید Microsoft.AspNetCore.Identity.UI است که به همراه ASP.NET Core 2.1 ارائه میشود:
dotnet add package Microsoft.AspNetCore.Identity.UI --version 2.1.0-rc1-final