Here’s the list of what’s new in this preview:
- Razor Components renamed back to server-side Blazor
- Client-side Blazor on WebAssembly now in official preview
- Resolve components based on
@using
- _Imports.razor
- New component item template
- Reconnection to the same server
- Stateful reconnection after prerendering
- Render stateful interactive components from Razor pages and views
- Detect when the app is prerendering
- Configure the SignalR client for server-side Blazor apps
- Improved SignalR reconnect features
- Configure SignalR client for server-side Blazor apps
- Additional options for MVC service registration
- Endpoint routing updates
- New template for gRPC
- Design-time build for gRPC
- New Worker SDK
Security in software development should be a first-order requirement, but it’s often implemented in projects as an afterthought. With Application Security in .NET Succinctly, author Stan Drapkin provides a refresher of .NET security practices and fills common knowledge gaps for experienced developers and novices alike. Learn about hashes, machine authentication code, key derivation, binary and text encodings, symmetric and authenticated encryption, and much more, and begin properly securing your .NET apps today.
- Preface
- .NET Security
- Hashes and MACs
- Key Derivation
- Comparing Byte Arrays
- Binary Encodings
- Text Encodings
- Symmetric Encryption
- Authenticated Encryption
- Asymmetric Cryptography
- Two-Factor Authentication (2FA)
- Web Security
مقایسه تعریف سطوح دسترسی «مبتنی بر نقشها» با سطوح دسترسی «مبتنی بر سیاستهای امنیتی»
- در سطوح دسترسی «مبتنی بر نقشها»
یکسری نقش از پیش تعریف شده وجود دارند؛ مانند PayingUser و یا FreeUser که کاربر توسط هر نقش، به یکسری دسترسیهای خاص نائل میشود. برای مثال PayingUser میتواند نگارش قاب شدهی تصاویر را سفارش دهد و یا تصویری را به سیستم اضافه کند.
- در سطوح دسترسی «مبتنی بر سیاستهای امنیتی»
سطوح دسترسی بر اساس یک سری سیاست که بیانگر ترکیبی از منطقهای دسترسی هستند، اعطاء میشوند. این منطقها نیز از طریق ترکیب User Claims حاصل میشوند و میتوانند منطقهای پیچیدهتری را به همراه داشته باشند. برای مثال اگر کاربری از کشور A است و نوع اشتراک او B است و اگر در بین یک بازهی زمانی خاصی متولد شده باشد، میتواند به منبع خاصی دسترسی پیدا کند. به این ترتیب حتی میتوان نیاز به ترکیب چندین نقش را با تعریف یک سیاست امنیتی جدید جایگزین کرد. به همین جهت نسبت به روش بکارگیری مستقیم کار با نقشها ترجیح داده میشود.
جایگزین کردن بررسی سطوح دسترسی توسط نقشها با روش بکارگیری سیاستهای دسترسی
در ادامه میخواهیم بجای بکارگیری مستقیم نقشها جهت محدود کردن دسترسی به قسمتهای خاصی از برنامهی کلاینت، تنها کاربرانی که از کشور خاصی وارد شدهاند و نیز سطح اشتراک خاصی را دارند، بتوانند دسترسیهای ویژهای داشته باشند؛ چون برای مثال امکان ارسال مستقیم تصاویر قاب شده را به کشور دیگری نداریم.
تنظیم User Claims جدید در برنامهی IDP
برای تنظیم این سیاست امنیتی جدید، ابتدا دو claim جدید subscriptionlevel و country را به خواص کاربران در کلاس src\IDP\DNT.IDP\Config.cs در سطح IDP اضافه میکنیم:
namespace DNT.IDP { public static class Config { public static List<TestUser> GetUsers() { return new List<TestUser> { new TestUser { Username = "User 1", // ... Claims = new List<Claim> { // ... new Claim("subscriptionlevel", "PayingUser"), new Claim("country", "ir") } }, new TestUser { Username = "User 2", // ... Claims = new List<Claim> { // ... new Claim("subscriptionlevel", "FreeUser"), new Claim("country", "be") } } }; }
namespace DNT.IDP { public static class Config { // identity-related resources (scopes) public static IEnumerable<IdentityResource> GetIdentityResources() { return new List<IdentityResource> { // ... new IdentityResource( name: "country", displayName: "The country you're living in", claimTypes: new List<string> { "country" }), new IdentityResource( name: "subscriptionlevel", displayName: "Your subscription level", claimTypes: new List<string> { "subscriptionlevel" }) }; }
namespace DNT.IDP { public static class Config { public static IEnumerable<Client> GetClients() { return new List<Client> { new Client { ClientName = "Image Gallery", // ... AllowedScopes = { // ... "country", "subscriptionlevel" } // ... } }; } }
استفادهی از User Claims جدید در برنامهی MVC Client
در ادامه به کلاس ImageGallery.MvcClient.WebApp\Startup.cs برنامهی MVC Client مراجعه کرده و دو scope جدیدی را که در سمت IDP تعریف کردیم، در اینجا در تنظیمات متد AddOpenIdConnect، درخواست میدهیم:
options.Scope.Add("subscriptionlevel"); options.Scope.Add("country");
البته همانطور که در قسمتهای قبل نیز ذکر شد، اگر claim ای در لیست نگاشتهای تنظیمات میانافزار OpenID Connect مایکروسافت نباشد، آنرا در لیست this.User.Claims ظاهر نمیکند. به همین جهت همانند claim role که پیشتر MapUniqueJsonKey را برای آن تعریف کردیم، نیاز است برای این دو claim نیز نگاشتهای لازم را به سیستم افزود:
options.ClaimActions.MapUniqueJsonKey(claimType: "role", jsonKey: "role"); options.ClaimActions.MapUniqueJsonKey(claimType: "subscriptionlevel", jsonKey: "subscriptionlevel"); options.ClaimActions.MapUniqueJsonKey(claimType: "country", jsonKey: "country");
ایجاد سیاستهای دسترسی در برنامهی MVC Client
برای تعریف یک سیاست دسترسی جدید در کلاس ImageGallery.MvcClient.WebApp\Startup.cs برنامهی MVC Client، به متد ConfigureServices آن مراجعه کرده و آنرا به صورت زیر تکمیل میکنیم:
namespace ImageGallery.MvcClient.WebApp { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddAuthorization(options => { options.AddPolicy( name: "CanOrderFrame", configurePolicy: policyBuilder => { policyBuilder.RequireAuthenticatedUser(); policyBuilder.RequireClaim(claimType: "country", requiredValues: "ir"); policyBuilder.RequireClaim(claimType: "subscriptionlevel", requiredValues: "PayingUser"); }); });
به علاوه policyBuilder شامل متد RequireRole نیز هست. به همین جهت است که این روش تعریف سطوح دسترسی، روش قدیمی مبتنی بر نقشها را جایگزین کرده و در برگیرندهی آن نیز میشود؛ چون در این سیستم، role نیز تنها یک claim است، مانند country و یا subscriptionlevel فوق.
بررسی نحوهی استفادهی از Authorization Policy تعریف شده و جایگزین کردن آن با روش بررسی نقشها
تا کنون از روش بررسی سطوح دسترسیها بر اساس نقشهای کاربران در دو قسمت استفاده کردهایم:
الف) اصلاح Views\Shared\_Layout.cshtml برای استفادهی از Authorization Policy
در فایل Layout با بررسی نقش PayingUser، منوهای مرتبط با این نقش را فعال میکنیم:
@if(User.IsInRole("PayingUser")) { <li><a asp-area="" asp-controller="Gallery" asp-action="AddImage">Add an image</a></li> <li><a asp-area="" asp-controller="Gallery" asp-action="OrderFrame">Order a framed picture</a></li> }
@using Microsoft.AspNetCore.Authorization @inject IAuthorizationService AuthorizationService
@if (User.IsInRole("PayingUser")) { <li><a asp-area="" asp-controller="Gallery" asp-action="AddImage">Add an image</a></li> } @if ((await AuthorizationService.AuthorizeAsync(User, "CanOrderFrame")).Succeeded) { <li><a asp-area="" asp-controller="Gallery" asp-action="OrderFrame">Order a framed picture</a></li> }
ب) اصلاح کنترلر ImageGallery.MvcClient.WebApp\Controllers\GalleryController.cs برای استفادهی از Authorization Policy
namespace ImageGallery.MvcClient.WebApp.Controllers { [Authorize] public class GalleryController : Controller { [Authorize(Policy = "CanOrderFrame")] public async Task<IActionResult> OrderFrame() {
اکنون برای آزمایش برنامه یکبار از آن خارج شده و سپس توسط اکانت User 1 که از نوع PayingUser در کشور ir است، به آن وارد شوید.
ابتدا به قسمت IdentityInformation آن وارد شوید. در اینجا لیست claims جدید را میتوانید مشاهده کنید. همچنین لینک سفارش تصویر قاب شده نیز نمایان است و میتوان به آدرس آن نیز وارد شد.
استفاده از سیاستهای دسترسی در سطح برنامهی Web API
در سمت برنامهی Web API، در حال حاضر کاربران میتوانند به متدهای Get ،Put و Delete ای که رکوردهای آنها الزاما متعلق به آنها نیست دسترسی داشته باشند. بنابراین نیاز است از ورود کاربران به متدهای تغییرات رکوردهایی که OwnerID آنها با هویت کاربری آنها تطابقی ندارد، جلوگیری کرد. در این حالت Authorization Policy تعریف شده نیاز دارد تا با سرویس کاربران و بانک اطلاعاتی کار کند. همچنین نیاز به دسترسی به اطلاعات مسیریابی جاری را برای دریافت ImageId دارد. پیاده سازی یک چنین سیاست دسترسی پیچیدهای توسط متدهای RequireClaim و RequireRole میسر نیست. خوشبختانه امکان بسط سیستم Authorization Policy با پیاده سازی یک IAuthorizationRequirement سفارشی وجود دارد. RequireClaim و RequireRole، جزو Authorization Requirementهای پیشفرض و توکار هستند. اما میتوان نمونههای سفارشی آنها را نیز پیاده سازی کرد:
using System; using System.Linq; using System.Threading.Tasks; using Microsoft.AspNetCore.Authorization; using Microsoft.AspNetCore.Mvc.Filters; using Microsoft.Extensions.Logging; namespace ImageGallery.WebApi.Services { public class MustOwnImageRequirement : IAuthorizationRequirement { } public class MustOwnImageHandler : AuthorizationHandler<MustOwnImageRequirement> { private readonly IImagesService _imagesService; private readonly ILogger<MustOwnImageHandler> _logger; public MustOwnImageHandler( IImagesService imagesService, ILogger<MustOwnImageHandler> logger) { _imagesService = imagesService; _logger = logger; } protected override async Task HandleRequirementAsync( AuthorizationHandlerContext context, MustOwnImageRequirement requirement) { var filterContext = context.Resource as AuthorizationFilterContext; if (filterContext == null) { context.Fail(); return; } var imageId = filterContext.RouteData.Values["id"].ToString(); if (!Guid.TryParse(imageId, out Guid imageIdAsGuid)) { _logger.LogError($"`{imageId}` is not a Guid."); context.Fail(); return; } var subClaim = context.User.Claims.FirstOrDefault(c => c.Type == "sub"); if (subClaim == null) { _logger.LogError($"User.Claims don't have the `sub` claim."); context.Fail(); return; } var ownerId = subClaim.Value; if (!await _imagesService.IsImageOwnerAsync(imageIdAsGuid, ownerId)) { _logger.LogError($"`{ownerId}` is not the owner of `{imageIdAsGuid}` image."); context.Fail(); return; } // all checks out context.Succeed(requirement); } } }
<Project Sdk="Microsoft.NET.Sdk"> <ItemGroup> <PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.1.0" /> <PackageReference Include="Microsoft.AspNetCore.Authorization" Version="2.1.1.0" /> <PackageReference Include="Microsoft.AspNetCore.Mvc.Abstractions" Version="2.1.1.0" /> </ItemGroup> </Project>
پیاده سازی سیاستهای پویای دسترسی شامل مراحل ذیل است:
1- تعریف یک نیازمندی دسترسی جدید
public class MustOwnImageRequirement : IAuthorizationRequirement { }
2- پیاده سازی یک AuthorizationHandler استفاده کنندهی از نیازمندی دسترسی تعریف شده
که کدهای کامل آنرا در کلاس MustOwnImageHandler مشاهده میکنید. کار آن با ارث بری از AuthorizationHandler شروع شده و آرگومان جنریک آن، همان نیازمندی است که پیشتر تعریف کردیم. از این آرگومان جنریک جهت یافتن خودکار AuthorizationHandler متناظر با آن توسط ASP.NET Core استفاده میشود. بنابراین در اینجا MustOwnImageRequirement تهیه شده صرفا کارکرد علامتگذاری را دارد.
در کلاس تهیه شده باید متد HandleRequirementAsync آنرا بازنویسی کرد و اگر در این بین، منطق سفارشی ما context.Succeed را فراخوانی کند، به معنای برآورده شدن سیاست دسترسی بوده و کاربر جاری میتواند به منبع درخواستی بلافاصله دسترسی یابد و اگر context.Fail فراخوانی شود، در همینجا دسترسی کاربر قطع شده و HTTP status code مساوی 401 (عدم دسترسی) را دریافت میکند.
در این پیاده سازی از filterContext.RouteData برای یافتن Id تصویر مورد نظر استفاده شدهاست. همچنین Id شخص جاری نیز از sub claim موجود استخراج گردیدهاست. اکنون این اطلاعات را به سرویس تصاویر ارسال میکنیم تا توسط متد IsImageOwnerAsync آن مشخص شود که آیا کاربر جاری سیستم، همان کاربری است که تصویر را در بانک اطلاعاتی ثبت کردهاست؟ اگر بله، با فراخوانی context.Succeed به سیستم Authorization اعلام خواهیم کرد که این سیاست دسترسی و نیازمندی مرتبط با آن با موفقیت پشت سر گذاشته شدهاست.
3- معرفی سیاست دسترسی پویای تهیه شده به سیستم
معرفی سیاست کاری پویا و سفارشی تهیه شده، شامل دو مرحلهی زیر است:
مراجعهی به کلاس ImageGallery.WebApi.WebApp\Startup.cs و افزودن نیازمندی آن:
namespace ImageGallery.WebApi.WebApp { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddAuthorization(authorizationOptions => { authorizationOptions.AddPolicy( name: "MustOwnImage", configurePolicy: policyBuilder => { policyBuilder.RequireAuthenticatedUser(); policyBuilder.AddRequirements(new MustOwnImageRequirement()); }); }); services.AddScoped<IAuthorizationHandler, MustOwnImageHandler>();
سپس یک Policy جدید را با نام دلخواه MustOwnImage تعریف کرده و نیازمندی علامتگذار خود را به عنوان یک policy.Requirements جدید، اضافه میکنیم. همانطور که ملاحظه میکنید یک وهلهی جدید از MustOwnImageRequirement در اینجا ثبت شدهاست. همین وهله به متد HandleRequirementAsync نیز ارسال میشود. بنابراین اگر نیاز به ارسال پارامترهای بیشتری به این متد وجود داشت، میتوان خواص مرتبطی را به کلاس MustOwnImageRequirement نیز اضافه کرد.
همانطور که مشخص است، در اینجا یک نیازمندی را میتوان ثبت کرد و نه Handler آنرا. این Handler از سیستم تزریق وابستگیها بر اساس آرگومان جنریک AuthorizationHandler پیاده سازی شده، به صورت خودکار یافت شده و اجرا میشود (بنابراین اگر Handler شما اجرا نشد، مطمئن شوید که حتما آنرا به سیستم تزریق وابستگیها معرفی کردهاید).
پس از آن هر کنترلر یا اکشن متدی که از این سیاست دسترسی پویای تهیه شده استفاده کند:
[Authorize(Policy ="MustOwnImage")]
اعمال سیاست دسترسی پویای تعریف شده به Web API
پس از تعریف سیاست دسترسی MustOwnImage که پویا عمل میکند، اکنون نوبت به استفادهی از آن در کنترلر ImageGallery.WebApi.WebApp\Controllers\ImagesController.cs است:
namespace ImageGallery.WebApi.WebApp.Controllers { [Route("api/images")] [Authorize] public class ImagesController : Controller { [HttpGet("{id}", Name = "GetImage")] [Authorize("MustOwnImage")] public async Task<IActionResult> GetImage(Guid id) { } [HttpDelete("{id}")] [Authorize("MustOwnImage")] public async Task<IActionResult> DeleteImage(Guid id) { } [HttpPut("{id}")] [Authorize("MustOwnImage")] public async Task<IActionResult> UpdateImage(Guid id, [FromBody] ImageForUpdateModel imageForUpdate) { } } }
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید.
برای اجرای برنامه:
- ابتدا به پوشهی src\WebApi\ImageGallery.WebApi.WebApp وارد شده و dotnet_run.bat آنرا اجرا کنید تا WebAPI برنامه راه اندازی شود.
- سپس به پوشهی src\IDP\DNT.IDP مراجعه کرده و و dotnet_run.bat آنرا اجرا کنید تا برنامهی IDP راه اندازی شود.
- در آخر به پوشهی src\MvcClient\ImageGallery.MvcClient.WebApp وارد شده و dotnet_run.bat آنرا اجرا کنید تا MVC Client راه اندازی شود.
اکنون که هر سه برنامه در حال اجرا هستند، مرورگر را گشوده و مسیر https://localhost:5001 را درخواست کنید. در صفحهی login نام کاربری را User 1 و کلمهی عبور آنرا password وارد کنید.
فناوریهایی برای مطالعه در سال 2017
- .NET Core
- Node.js
- Docker
- Elasticsearch: A distributed and open source search engine based on Lucene. A blazing fast NoSQL database with replication capabilities, it is the most widely known component of the ELK stack, together with Kibana (for reporting and visualizations), Logstash (for data import) and Beats (for data shipping). Even Azure Search uses it behind the covers. Free but some tools are paid. Get it from http://elastic.co.
- ECMAScript 2015
- HTML5
- Kafka
- TypeScript
- MongoDB
- Git
- Nginx
- Octopus Deploy
- Azure
- Amazon Web Services
- Linux
- Visual Studio Code
- Xamarin
- Google Analytics
- SQL Server 2016
- Let’s Encrypt
- TensorFlow
- GitLab
- Redis
بزرگترین تغییرات با C# 9.0 و NET 5.
دوره توسعه Universal Windows Apps
*در دنیای NoSql پیاده سازیهای متفاوتی از دیتابیسها انجام شده است و هر دیتابیس، ویژگیها و مزایا و معایب خاص خودش را دارد. باید قبول کرد که همیشه و همه جا نمیتوان از یک پایگاه داده NoSql مشخص استفاده نماییم (دلایلی نظیر محدودیتهای License، هزینه پیاده سازی و...). در نتیجه بررسی یک دیتابیس دیگر با شرایط و توانمندیهای خاص آن خالی از سود نیست.
» این دیتاییس در گروه Graph databasesها قرار دارد و از زبان SPARQL (بخوانید Sparkle) برای کوئری گرفتن و کار با دادهها بهره میبرد؛
» متن باز و رایگان است
» پشتیبانی از دات نت چهار به بعد؛
» قابل استفاده در Mobile Application - Windows phone 7 , 8؛
» بدون شما (Schema Less) و با قابیلت ذخیره سازی triple و به فرمت RDF
» پشتیبانی از Linq و OData؛
» پشتیبانی از تراکنشها ؛
» پیاده سازی مدل برنامه به صورت Code First؛
» سرعت بالا جهت ذخیره سازی و لود اطلاعات؛
» نیاز به پیکربندیهای خاص جهت پیاده سازی ندارد؛
» ارائه افزونه رایگان Polaris جهت کوئری گفتن و نمایش Visual داده ها.
و غیره که در ادامه با آنها آشنا خواهید شد.
در B*Db دو روش برای ذخیره سازی اطلاعات وجود دارد:
» Append Only : در این روش تمامی تغییرات (عملیات نوشتن) در انتهای فایل index اضافه خواهد شد. این روش مزایای زیر را به دنبال خواهد داشت:
- عملیات نوشتن هیچگاه عملیات خواندن اطلاعات را block نمیکند. در
نتیجه هر تعداد عملیات خواندن فایل (منظور اجرای کوئریهای SPQRL است) میتواند به صورت موازی بر روی Storeها اجرا شود.
- به دلیل اینکه عمل ویرایش واقعی هیچ گاه انجام نمیشود (دادهها فقط اضافه خواهند شد) همیشه میتوانید وضعیت Store را به حالتهای قبلی بازگردانید.
- عملیات نوشتن اطلاعات بسیار سریع خواهد بود.
نکته ای که باید به آن دقت داشت این است که فقط در هنگام ساخت Storeها میتوانید نوع ذخیره سازی آن را تعیین نمایید، بعد از ساخت Store امکان سوئیچ بین حالات امکان پذیر نیست.
همان طور که پیشتر گفته شد B*Db برای ذخیره سازی اطلاعات از سند RDF بهره میبرد. البته با RDF Syntaxهای متفاوت :
هم چنین در B*Db چهار روش برای دست یابی با دادهها (پیاده سازی عملیات CRUD) وجود دارد از قبیل:
» B*Db EntityFramewok
» Data Object Layer
» RDF Client Api
» Dynamic API
که هر کدام در طی پستهای متفاوت بررسی خواهد شد.
بررسی یک مثال با روش B*Db EntityFramework
برای شروع ابتدا یک پروژه جدید از نوع Console Application ایجاد کنید. سپس از طریق Nuget اقدام به نصب Package زیر نمایید:
pm> install-Package BirghtStarDb
PM> Install-Package BirghtStarDbLibs
بعد از نصب پکیجهای بالا یک فایل Text Template با نام MyEntityContext.tt نیز به پروژه افزوده خواهد شد. این فایل جهت تولید خودکار مدلهای برنامه استفاده میشود. اما برای این کار لازم است به ازای هر مدل ابتدا یک اینترفیس ایجاد نمایید. برای مثال:
[Entity] public interface IBook { public int Code { get; set; } public string Title { get; set; } }
» نیاز به ایجاد یک خاصیت به عنوان Id وجود ندارد. به صورت پیش فرض خاصیت Id با نوع string برای هر مدل پیاده سازی میشود. اما اگر قصد دارید این نام خاصیت را تغییر دهید میتوانید به صورت زیر عمل کنید:
[Entity] public interface IBook { [Identifier] public string MyId { get; } public int Code { get; set; } public string Title { get; set; } }
استفاده از اینترفیس برای ساخت مدل انعطاف پذیری بالایی را در اختیار ما قرار میدهد که بعدا مفصل بحث خواهد شد. برای عملیات درج داده میتوان به صورت زیر عمل کنید:
MyEntityContext context = new MyEntityContext("type=embedded;storesdirectory=c:\brightstar;storename=test"); var book = context.Books.Create(); book.Code = 1; book.Title = "Test"; context.Books.Add(book); context.SaveChanges();
»embedded : در این حالت از طریق آدرس فیزیکی فایل مورد نظر میتوان یک Connection ایجاد کرد.
»rest : یا استفاده از HTTP یا HTTPS میتوان به سرویس B*Db دسترسی داشت.
»dotNetRdf : برای ارتباط با یک Store دیگر با استفاده از اتصال دهندههای DotNetRDf.
»sparql : اتصال به منبع داده ای دیگر با استفاده از پروتکل SPARQL
در هنگام ایجاد اتصال باید نوع مورد نظر را از حتما تعیین نمایید. با استفاده از storedirctory مکان فیزیکی فایل تعیین خواهد شد.