Implement ASP.NET Core OpenID Connect OAuth PAR client with Keycloak using .NET Aspire
This post shows how to implement an ASP.NET Core application which uses OpenID Connect and OAuth PAR for authentication. The client application uses Keycloak as the identity provider. The Keycloak application is hosted in a docker container. The applications are run locally using .NET Aspire. This makes it really easy to develop using containers.
Anti-forgery tokens یک مکانیزم امنیتی، جهت مقابله با حملات CSRF هستند. در برنامههای ASP.NET Core، فرمهای دارای Tag Helper مانند asp-controller و asp-action به صورت خودکار دارای یک فیلد مخفی حاوی این token، به همراه تولید یک کوکی مخصوص جهت تعیین اعتبار آن خواهند بود. البته در برنامههای ASP.NET Core 2.0 تمام فرمها، چه حاوی Tag Helpers باشند یا خیر، به همراه درج این توکن تولید میشوند.
برای مثال در برنامههای ASP.NET Core، یک چنین فرمی:
به صورت ذیل رندر میشود که حاوی قسمتی از Anti-forgery token است و قسمت دیگر آن در کوکی مرتبط درج میشود:
در این مطلب چگونگی شبیه سازی این عملیات را در برنامههای Angular که تمام تبادلات آنها Ajax ایی است، بررسی خواهیم کرد.
تولید خودکار کوکیهای Anti-forgery tokens برای برنامههای Angular
در سمت Angular، مطابق مستندات رسمی آن (^ و ^)، اگر کوکی تولید شدهی توسط برنامه، دارای نام مشخص «XSRF-TOKEN» باشد، کتابخانهی HTTP آن به صورت خودکار مقدار آنرا استخراج کرده و به درخواست بعدی ارسالی آن اضافه میکند. بنابراین در سمت ASP.NET Core تنها کافی است کوکی مخصوص فوق را تولید کرده و به Response اضافه کنیم. مابقی آن توسط Angular به صورت خودکار مدیریت میشود.
میتوان اینکار را مستقیما داخل متد Configure کلاس آغازین برنامه انجام داد و یا بهتر است جهت حجیم نشدن این فایل و مدیریت مجزای این مسئولیت، یک میانافزار مخصوص آنرا تهیه کرد:
توضیحات تکمیلی:
- در اینجا ابتدا سرویس IAntiforgery به سازندهی کلاس میان افزار تزریق شدهاست. به این ترتیب میتوان به سرویس توکار تولید توکنهای Antiforgery دسترسی یافت. سپس از این سرویس جهت دسترسی به متد GetAndStoreTokens آن برای دریافت محتوای رشتهای نهایی این توکن استفاده میشود.
- اکنون که به این توکن دسترسی پیدا کردهایم، تنها کافی است آنرا با کلید مخصوص XSRF-TOKEN که توسط Angular شناسایی میشود، به مجموعهی کوکیهای Response اضافه کنیم.
- علت تنظیم مقدار خاصیت HttpOnly به false، این است که کدهای جاوا اسکریپتی Angular بتوانند به مقدار این کوکی دسترسی پیدا کنند.
پس از تدارک این مقدمات، کافی است متد الحاقی کمکی UseAntiforgeryToken فوق را به نحو ذیل به متد Configure کلاس آغازین برنامه اضافه کنیم؛ تا کار نصب میان افزار AntiforgeryTokenMiddleware، تکمیل شود:
پردازش خودکار درخواستهای ارسالی از طرف Angular
تا اینجا برنامهی سمت سرور ما کوکیهای مخصوص Angular را با کلیدی که توسط آن شناسایی میشود، تولید کردهاست. در پاسخ، Angular این کوکی را در هدر مخصوصی به نام «X-XSRF-TOKEN» به سمت سرور ارسال میکند (ابتدای آن یک X اضافهتر دارد).
به همین جهت به متد ConfigureServices کلاس آغازین برنامه مراجعه کرده و این هدر مخصوص را معرفی میکنیم تا دقیقا مشخص گردد، این توکن از چه قسمتی باید جهت پردازش استخراج شود:
یک نکته: اگر میخواهید این کلیدهای هدر پیش فرض Angular را تغییر دهید، باید یک CookieXSRFStrategy سفارشی را برای آن تهیه کنید.
اعتبارسنجی خودکار Anti-forgery tokens در برنامههای ASP.NET Core
ارسال کوکی اطلاعات Anti-forgery tokens و سپس دریافت آن توسط برنامه، تنها یک قسمت از کار است. قسمت بعدی، بررسی معتبر بودن آنها در سمت سرور است. روش متداول انجام اینکار، افزودن ویژگی [ValidateAntiForgeryToken] به هر اکشن متد مزین به [HttpPost] است:
هرچند این روش کار میکند، اما در ASP.NET Core، فیلتر توکار دیگری به نام AutoValidateAntiForgeryToken نیز وجود دارد. کار آن دقیقا همانند فیلتر ValidateAntiForgeryToken است؛ با این تفاوت که از حالتهای امنی مانند GET و HEAD صرفنظر میکند. بنابراین تنها کاری را که باید انجام داد، معرفی این فیلتر توکار به صورت یک فیلتر سراسری است، تا به تمام اکشن متدهای HttpPost برنامه به صورت خودکار اعمال شود:
به این ترتیب دیگر نیازی نیست تا ویژگی ValidateAntiForgeryToken را به تک تک اکشن متدهای از نوع HttpPost برنامه به صورت دستی اعمال کرد.
یک نکته: در این حالت بررسی سراسری، اگر در موارد خاصی نیاز به این اعتبارسنجی خودکار نبود، میتوان از ویژگی [IgnoreAntiforgeryToken] استفاده کرد.
آزمایش برنامه
برای آزمایش مواردی را که تا کنون بررسی کردیم، همان مثال «فرمهای مبتنی بر قالبها در Angular - قسمت پنجم - ارسال اطلاعات به سرور» را بر اساس نکات متدهای ConfigureServices و Configure مطلب جاری تکمیل میکنیم. سپس برنامه را اجرا میکنیم:
همانطور که ملاحظه میکنید، در اولین بار درخواست برنامه، کوکی مخصوص Angular تولید شدهاست.
در ادامه اگر فرم را تکمیل کرده و ارسال کنیم، وجود هدر ارسالی از طرف Angular مشخص است و همچنین خروجی هم با موفقیت دریافت شدهاست:
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: angular-template-driven-forms-lab-09.zip
برای اجرای آن فرض بر این است که پیشتر Angular CLI را نصب کردهاید. سپس به ریشهی پروژه وارد شده و دو پنجرهی کنسول مجزا را باز کنید. در اولی دستورات
و در دومی دستورات ذیل را اجرا کنید:
اکنون میتوانید برنامه را در آدرس http://localhost:5000 مشاهده و اجرا کنید.
برای مثال در برنامههای ASP.NET Core، یک چنین فرمی:
<form asp-controller="Manage" asp-action="ChangePassword" method="post"> <!-- Form details --> </form>
<form method="post" action="/Manage/ChangePassword"> <!-- Form details --> <input name="__RequestVerificationToken" type="hidden" value="CfDJ8NrAkSldwD9CpLR...LongValueHere!" /> </form>
تولید خودکار کوکیهای Anti-forgery tokens برای برنامههای Angular
در سمت Angular، مطابق مستندات رسمی آن (^ و ^)، اگر کوکی تولید شدهی توسط برنامه، دارای نام مشخص «XSRF-TOKEN» باشد، کتابخانهی HTTP آن به صورت خودکار مقدار آنرا استخراج کرده و به درخواست بعدی ارسالی آن اضافه میکند. بنابراین در سمت ASP.NET Core تنها کافی است کوکی مخصوص فوق را تولید کرده و به Response اضافه کنیم. مابقی آن توسط Angular به صورت خودکار مدیریت میشود.
میتوان اینکار را مستقیما داخل متد Configure کلاس آغازین برنامه انجام داد و یا بهتر است جهت حجیم نشدن این فایل و مدیریت مجزای این مسئولیت، یک میانافزار مخصوص آنرا تهیه کرد:
using System; using System.Threading.Tasks; using Microsoft.AspNetCore.Antiforgery; using Microsoft.AspNetCore.Builder; using Microsoft.AspNetCore.Http; namespace AngularTemplateDrivenFormsLab.Utils { public class AntiforgeryTokenMiddleware { private readonly RequestDelegate _next; private readonly IAntiforgery _antiforgery; public AntiforgeryTokenMiddleware(RequestDelegate next, IAntiforgery antiforgery) { _next = next; _antiforgery = antiforgery; } public Task Invoke(HttpContext context) { var path = context.Request.Path.Value; if (path != null && !path.StartsWith("/api/", StringComparison.OrdinalIgnoreCase)) { var tokens = _antiforgery.GetAndStoreTokens(context); context.Response.Cookies.Append( key: "XSRF-TOKEN", value: tokens.RequestToken, options: new CookieOptions { HttpOnly = false // Now JavaScript is able to read the cookie }); } return _next(context); } } public static class AntiforgeryTokenMiddlewareExtensions { public static IApplicationBuilder UseAntiforgeryToken(this IApplicationBuilder builder) { return builder.UseMiddleware<AntiforgeryTokenMiddleware>(); } } }
- در اینجا ابتدا سرویس IAntiforgery به سازندهی کلاس میان افزار تزریق شدهاست. به این ترتیب میتوان به سرویس توکار تولید توکنهای Antiforgery دسترسی یافت. سپس از این سرویس جهت دسترسی به متد GetAndStoreTokens آن برای دریافت محتوای رشتهای نهایی این توکن استفاده میشود.
- اکنون که به این توکن دسترسی پیدا کردهایم، تنها کافی است آنرا با کلید مخصوص XSRF-TOKEN که توسط Angular شناسایی میشود، به مجموعهی کوکیهای Response اضافه کنیم.
- علت تنظیم مقدار خاصیت HttpOnly به false، این است که کدهای جاوا اسکریپتی Angular بتوانند به مقدار این کوکی دسترسی پیدا کنند.
پس از تدارک این مقدمات، کافی است متد الحاقی کمکی UseAntiforgeryToken فوق را به نحو ذیل به متد Configure کلاس آغازین برنامه اضافه کنیم؛ تا کار نصب میان افزار AntiforgeryTokenMiddleware، تکمیل شود:
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) { app.UseAntiforgeryToken();
پردازش خودکار درخواستهای ارسالی از طرف Angular
تا اینجا برنامهی سمت سرور ما کوکیهای مخصوص Angular را با کلیدی که توسط آن شناسایی میشود، تولید کردهاست. در پاسخ، Angular این کوکی را در هدر مخصوصی به نام «X-XSRF-TOKEN» به سمت سرور ارسال میکند (ابتدای آن یک X اضافهتر دارد).
به همین جهت به متد ConfigureServices کلاس آغازین برنامه مراجعه کرده و این هدر مخصوص را معرفی میکنیم تا دقیقا مشخص گردد، این توکن از چه قسمتی باید جهت پردازش استخراج شود:
public void ConfigureServices(IServiceCollection services) { services.AddAntiforgery(x => x.HeaderName = "X-XSRF-TOKEN"); services.AddMvc(); }
یک نکته: اگر میخواهید این کلیدهای هدر پیش فرض Angular را تغییر دهید، باید یک CookieXSRFStrategy سفارشی را برای آن تهیه کنید.
اعتبارسنجی خودکار Anti-forgery tokens در برنامههای ASP.NET Core
ارسال کوکی اطلاعات Anti-forgery tokens و سپس دریافت آن توسط برنامه، تنها یک قسمت از کار است. قسمت بعدی، بررسی معتبر بودن آنها در سمت سرور است. روش متداول انجام اینکار، افزودن ویژگی [ValidateAntiForgeryToken] به هر اکشن متد مزین به [HttpPost] است:
[HttpPost] [ValidateAntiForgeryToken] public IActionResult ChangePassword() { // ... return Json(…); }
public void ConfigureServices(IServiceCollection services) { services.AddAntiforgery(x => x.HeaderName = "X-XSRF-TOKEN"); services.AddMvc(options => { options.Filters.Add(new AutoValidateAntiforgeryTokenAttribute()); }); }
یک نکته: در این حالت بررسی سراسری، اگر در موارد خاصی نیاز به این اعتبارسنجی خودکار نبود، میتوان از ویژگی [IgnoreAntiforgeryToken] استفاده کرد.
آزمایش برنامه
برای آزمایش مواردی را که تا کنون بررسی کردیم، همان مثال «فرمهای مبتنی بر قالبها در Angular - قسمت پنجم - ارسال اطلاعات به سرور» را بر اساس نکات متدهای ConfigureServices و Configure مطلب جاری تکمیل میکنیم. سپس برنامه را اجرا میکنیم:
همانطور که ملاحظه میکنید، در اولین بار درخواست برنامه، کوکی مخصوص Angular تولید شدهاست.
در ادامه اگر فرم را تکمیل کرده و ارسال کنیم، وجود هدر ارسالی از طرف Angular مشخص است و همچنین خروجی هم با موفقیت دریافت شدهاست:
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: angular-template-driven-forms-lab-09.zip
برای اجرای آن فرض بر این است که پیشتر Angular CLI را نصب کردهاید. سپس به ریشهی پروژه وارد شده و دو پنجرهی کنسول مجزا را باز کنید. در اولی دستورات
>npm install >ng build --watch
>dotnet restore >dotnet watch run
پیشتر مطلب «افزودن هدرهای Content Security Policy به برنامههای ASP.NET» را در این سایت مطالعه کردهاید. در اینجا قصد داریم معادل آنرا برای ASP.NET Core تهیه کرده و همچنین نکات مرتبط با برنامههای Angular را نیز در آن لحاظ کنیم.
تهیه میان افزار افزودن هدرهای Content Security Policy
کدهای کامل این میان افزار را در ادامه مشاهده میکنید:
که نحوهی استفاده از آن در کلاس آغازین برنامه به صورت ذیل خواهد بود:
توضیحات تکمیلی
افزودن X-Frame-Options
از هدر X-FRAME-OPTIONS، جهت منع نمایش و رندر سایت جاری، در iframeهای سایتهای دیگر استفاده میشود. ذکر مقدار SAMEORIGIN آن، به معنای مجاز تلقی کردن دومین جاری برنامه است.
افزودن X-Xss-Protection
تقریبا تمام مرورگرهای امروزی قابلیت تشخیص حملات XSS را توسط static analysis توکار خود دارند. این هدر، آنالیز اجباری XSS را فعال کرده و همچنین تنظیم حالت آن به block، نمایش و رندر قسمت مشکلدار را به طور کامل غیرفعال میکند.
افزودن X-Content-Type-Options
وجود این هدر سبب میشود تا مرورگر، حدسزدن نوع فایلها، درخواستها و محتوا را کنار گذاشته و صرفا به content-type ارسالی توسط سرور اکتفا کند. به این ترتیب برای مثال امکان لینک کردن یک فایل غیرجاوا اسکریپتی و اجرای آن به صورت کدهای جاوا اسکریپت، چون توسط تگ script ذکر شدهاست، غیرفعال میشود. در غیراینصورت مرورگر هرچیزی را که توسط تگ script به صفحه لینک شده باشد، صرف نظر از content-type واقعی آن، اجرا خواهد کرد.
افزودن Content-Security-Policy
وجود این هدر، تزریق کدها و منابع را از دومینهای دیگر غیرممکن میکند. برای مثال ذکر self در اینجا به معنای مجاز بودن الصاق و اجرای اسکریپتها، شیوهنامهها، تصاویر و اشیاء، صرفا از طریق دومین جاری برنامه است و هرگونه منبعی که از دومینهای دیگر به برنامه تزریق شود، قابلیت اجرایی و یا نمایشی نخواهد داشت.
در اینجا ذکر unsafe-inline و unsafe-eval را مشاهده میکنید. برنامههای Angular به همراه شیوهنامههای inline و یا بکارگیری متد eval در مواردی خاص هستند. اگر این دو گزینه ذکر و فعال نشوند، در کنسول developer مرورگر، خطای بلاک شدن آنها را مشاهده کرده و همچنین برنامه از کار خواهد افتاد.
یک نکته: با فعالسازی گزینهی aot-- در حین ساخت برنامه، میتوان unsafe-eval را نیز حذف کرد.
استفاده از فایل web.config برای تعریف SameSite Cookies
یکی از پیشنهادهای اخیر ارائه شدهی جهت مقابلهی با حملات CSRF و XSRF، قابلیتی است به نام Same-Site Cookies. به این ترتیب مرورگر، کوکی سایت جاری را به همراه یک درخواست ارسال آن به سایت دیگر، پیوست نمیکند (کاری که هم اکنون با درخواستهای Cross-Site صورت میگیرد). برای رفع این مشکل، با این پیشنهاد امنیتی جدید، تنها کافی است SameSite، به انتهای کوکی اضافه شود:
نگارشهای بعدی ASP.NET Core، ویژگی SameSite را نیز به عنوان CookieOptions لحاظ کردهاند. همچنین یک سری از کوکیهای خودکار تولیدی توسط آن مانند کوکیهای anti-forgery به صورت خودکار با این ویژگی تولید میشوند.
اما مدیریت این مورد برای اعمال سراسری آن، با کدنویسی میسر نیست (مگر اینکه مانند نگارشهای بعدی ASP.NET Core پشتیبانی توکاری از آن صورت گیرد). به همین جهت میتوان از ماژول URL rewrite مربوط به IIS برای افزودن ویژگی SameSite به تمام کوکیهای تولید شدهی توسط سایت، کمک گرفت. برای این منظور تنها کافی است فایل web.config را ویرایش کرده و موارد ذیل را به آن اضافه کنید:
لاگ کردن منابع بلاک شدهی توسط مرورگر در سمت سرور
اگر به هدر Content-Security-Policy دقت کنید، گزینهی آخر آن، ذکر اکشن متدی در سمت سرور است:
با تنظیم این مورد، میتوان موارد بلاک شده را در سمت سرور لاگ کرد. اما این اطلاعات ارسالی به سمت سرور، فرمت خاصی را دارند:
به همین جهت ابتدا نیاز است توسط JsonProperty کتابخانهی JSON.NET، معادل این خواص را تولید کرد:
اکنون میتوان بدنهی درخواست را استخراج و سپس به این شیء ویژه نگاشت کرد:
در اینجا نحوهی استخراج Request.Body را به صورت خام را مشاهده میکنید. سپس توسط متد DeserializeObject کتابخانهی JSON.NET، این رشته به شیء CspPost نگاشت شدهاست.
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید.
تهیه میان افزار افزودن هدرهای Content Security Policy
کدهای کامل این میان افزار را در ادامه مشاهده میکنید:
using System.Threading.Tasks; using Microsoft.AspNetCore.Builder; using Microsoft.AspNetCore.Http; namespace AngularTemplateDrivenFormsLab.Utils { public class ContentSecurityPolicyMiddleware { private readonly RequestDelegate _next; public ContentSecurityPolicyMiddleware(RequestDelegate next) { _next = next; } public Task Invoke(HttpContext context) { context.Response.Headers.Add("X-Frame-Options", "SAMEORIGIN"); context.Response.Headers.Add("X-Xss-Protection", "1; mode=block"); context.Response.Headers.Add("X-Content-Type-Options", "nosniff"); string[] csp = { "default-src 'self'", "style-src 'self' 'unsafe-inline'", "script-src 'self' 'unsafe-inline' 'unsafe-eval'", "font-src 'self'", "img-src 'self' data:", "connect-src 'self'", "media-src 'self'", "object-src 'self'", "report-uri /api/CspReport/Log" //TODO: Add api/CspReport/Log }; context.Response.Headers.Add("Content-Security-Policy", string.Join("; ", csp)); return _next(context); } } public static class ContentSecurityPolicyMiddlewareExtensions { /// <summary> /// Make sure you add this code BEFORE app.UseStaticFiles();, /// otherwise the headers will not be applied to your static files. /// </summary> public static IApplicationBuilder UseContentSecurityPolicy(this IApplicationBuilder builder) { return builder.UseMiddleware<ContentSecurityPolicyMiddleware>(); } } }
public void Configure(IApplicationBuilder app) { app.UseContentSecurityPolicy();
توضیحات تکمیلی
افزودن X-Frame-Options
context.Response.Headers.Add("X-Frame-Options", "SAMEORIGIN");
افزودن X-Xss-Protection
context.Response.Headers.Add("X-Xss-Protection", "1; mode=block");
افزودن X-Content-Type-Options
context.Response.Headers.Add("X-Content-Type-Options", "nosniff");
افزودن Content-Security-Policy
string[] csp = { "default-src 'self'", "style-src 'self' 'unsafe-inline'", "script-src 'self' 'unsafe-inline' 'unsafe-eval'", "font-src 'self'", "img-src 'self' data:", "connect-src 'self'", "media-src 'self'", "object-src 'self'", "report-uri /api/CspReport/Log" //TODO: Add api/CspReport/Log }; context.Response.Headers.Add("Content-Security-Policy", string.Join("; ", csp));
در اینجا ذکر unsafe-inline و unsafe-eval را مشاهده میکنید. برنامههای Angular به همراه شیوهنامههای inline و یا بکارگیری متد eval در مواردی خاص هستند. اگر این دو گزینه ذکر و فعال نشوند، در کنسول developer مرورگر، خطای بلاک شدن آنها را مشاهده کرده و همچنین برنامه از کار خواهد افتاد.
یک نکته: با فعالسازی گزینهی aot-- در حین ساخت برنامه، میتوان unsafe-eval را نیز حذف کرد.
استفاده از فایل web.config برای تعریف SameSite Cookies
یکی از پیشنهادهای اخیر ارائه شدهی جهت مقابلهی با حملات CSRF و XSRF، قابلیتی است به نام Same-Site Cookies. به این ترتیب مرورگر، کوکی سایت جاری را به همراه یک درخواست ارسال آن به سایت دیگر، پیوست نمیکند (کاری که هم اکنون با درخواستهای Cross-Site صورت میگیرد). برای رفع این مشکل، با این پیشنهاد امنیتی جدید، تنها کافی است SameSite، به انتهای کوکی اضافه شود:
Set-Cookie: sess=abc123; path=/; SameSite
نگارشهای بعدی ASP.NET Core، ویژگی SameSite را نیز به عنوان CookieOptions لحاظ کردهاند. همچنین یک سری از کوکیهای خودکار تولیدی توسط آن مانند کوکیهای anti-forgery به صورت خودکار با این ویژگی تولید میشوند.
اما مدیریت این مورد برای اعمال سراسری آن، با کدنویسی میسر نیست (مگر اینکه مانند نگارشهای بعدی ASP.NET Core پشتیبانی توکاری از آن صورت گیرد). به همین جهت میتوان از ماژول URL rewrite مربوط به IIS برای افزودن ویژگی SameSite به تمام کوکیهای تولید شدهی توسط سایت، کمک گرفت. برای این منظور تنها کافی است فایل web.config را ویرایش کرده و موارد ذیل را به آن اضافه کنید:
<?xml version="1.0" encoding="utf-8"?> <configuration> <system.webServer> <rewrite> <outboundRules> <clear /> <!-- https://scotthelme.co.uk/csrf-is-dead/ --> <rule name="Add SameSite" preCondition="No SameSite"> <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" negate="false" /> <action type="Rewrite" value="{R:0}; SameSite=lax" /> <conditions></conditions> </rule> <preConditions> <preCondition name="No SameSite"> <add input="{RESPONSE_Set_Cookie}" pattern="." /> <add input="{RESPONSE_Set_Cookie}" pattern="; SameSite=lax" negate="true" /> </preCondition> </preConditions> </outboundRules> </rewrite> </system.webServer> </configuration>
لاگ کردن منابع بلاک شدهی توسط مرورگر در سمت سرور
اگر به هدر Content-Security-Policy دقت کنید، گزینهی آخر آن، ذکر اکشن متدی در سمت سرور است:
"report-uri /api/CspReport/Log" //TODO: Add api/CspReport/Log
{ "csp-report": { "document-uri": "http://localhost:5000/untypedSha", "referrer": "", "violated-directive": "script-src", "effective-directive": "script-src", "original-policy": "default-src 'self'; style-src 'self'; script-src 'self'; font-src 'self'; img-src 'self' data:; connect-src 'self'; media-src 'self'; object-src 'self'; report-uri /api/Home/CspReport", "disposition": "enforce", "blocked-uri": "eval", "line-number": 21, "column-number": 8, "source-file": "http://localhost:5000/scripts.bundle.js", "status-code": 200, "script-sample": "" } }
class CspPost { [JsonProperty("csp-report")] public CspReport CspReport { get; set; } } class CspReport { [JsonProperty("document-uri")] public string DocumentUri { get; set; } [JsonProperty("referrer")] public string Referrer { get; set; } [JsonProperty("violated-directive")] public string ViolatedDirective { get; set; } [JsonProperty("effective-directive")] public string EffectiveDirective { get; set; } [JsonProperty("original-policy")] public string OriginalPolicy { get; set; } [JsonProperty("disposition")] public string Disposition { get; set; } [JsonProperty("blocked-uri")] public string BlockedUri { get; set; } [JsonProperty("line-number")] public int LineNumber { get; set; } [JsonProperty("column-number")] public int ColumnNumber { get; set; } [JsonProperty("source-file")] public string SourceFile { get; set; } [JsonProperty("status-code")] public string StatusCode { get; set; } [JsonProperty("script-sample")] public string ScriptSample { get; set; } }
namespace AngularTemplateDrivenFormsLab.Controllers { [Route("api/[controller]")] public class CspReportController : Controller { [HttpPost("[action]")] [IgnoreAntiforgeryToken] public async Task<IActionResult> Log() { CspPost cspPost; using (var bodyReader = new StreamReader(this.HttpContext.Request.Body)) { var body = await bodyReader.ReadToEndAsync().ConfigureAwait(false); this.HttpContext.Request.Body = new MemoryStream(Encoding.UTF8.GetBytes(body)); cspPost = JsonConvert.DeserializeObject<CspPost>(body); } //TODO: log cspPost return Ok(); } } }
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید.
Keycloak.AuthServices provides robust authentication mechanisms for both web APIs and web applications. For web APIs, it supports JWT Bearer token authentication, which allows clients to authenticate to the API by providing a JWT token in the Authorization header of their requests. For web applications, it supports OpenID Connect, a simple identity layer on top of the OAuth 2.0 protocol, which allows clients to verify the identity of the end-user, obtain basic profile information about the end-user, etc.
.NET Web API with Keycloak
In this article, we will explore the advantages of using Keycloak, an open-source identity and access management solution. With Keycloak, you can easily add authentication and authorization to your applications, benefiting from the robustness of a proven system instead of building your own. This allows you to avoid the complexities and security challenges of managing application access control on your own.
مسیرراهها
ASP.NET Core
ASP.NET Core 1.0
- قسمت اول: Net Core. چیست؟
- قسمت دوم: بررسی ساختار جدید Solution
- قسمت سوم: Middleware چیست؟
- قسمت چهارم: فعالسازی پردازش فایلهای استاتیک
- قسمت پنجم: فعالسازی صفحات مخصوص توسعه دهنده ها
- قسمت ششم: سرویسها و تزریق وابستگی ها
- قسمت هفتم: کار با فایلهای Config
- قسمت هشتم: فعالسازی ASP.NET MVC
- قسمت نهم: بررسی تغییرات مسیریابی
- قسمت دهم: بررسی تغییرات Viewها
- قسمت یازدهم: بررسی بهبودهای Razor
- قسمت دوازدهم: معرفی Tag Helpers
- قسمت سیزدهم: معرفی View Components
- قسمت چهاردهم: فعال سازی اعتبارسنجی ورودیهای کاربران
- قسمت پانزدهم: بررسی تغییرات Caching
- قسمت شانزدهم:کار با Sessions
- قسمت هفدهم: بررسی فریم ورک Logging
- قسمت هجدهم: کار با ASP.NET Web API
- قسمت نوزدهم: بومی سازی
- قسمت بیستم: بررسی تغییرات فیلترها
- قسمت بیست و یکم: بررسی تغییرات Bundling و Minification
- قسمت بیست و دوم: توزیع برنامه توسط IIS
- پیاده سازی Unobtrusive Ajax در ASP.NET Core 1.0
ASP.NET Core 2.0
- امکان استفادهی مستقیم از کتابخانههای Full .NET Framework در NET Core 2.0.
- Tag Helper Components در ASP.NET Core 2.0
- کار با Razor در ASP.NET Core 2.0
- فعالسازی Windows Authentication در برنامههای ASP.NET Core 2.0
ASP.NET Core 2.1
روش ارتقاء
ASP.NET Core Identity
کار با Areas در ASP.NET Core
کار با کوکیها در ASP.NET Core
بررسی روش آپلود فایلها در ASP.NET Core
ارسال ایمیل در ASP.NET Core
نوشتن Middleware سفارشی در ASP.NET Core
نوشتن TagHelperهای سفارشی برای ASP.NET Core
بررسی تغییرات Reflection در NET Core.
استفادهی گسترده از DateTimeOffset در NET Core.
بررسی روش دسترسی به HttpContext در ASP.NET Core
توزیع پروژههای ASP.NET Core 1.1 بدون ارائه فایلهای View آن
تغییرات رمزنگاری اطلاعات در NET Core.
ساخت بستههای نیوگت مخصوص NET Core.
تهیه قالب برای ارسال ایمیلها در ASP.NET Core توسط Razor Viewها
روش یافتن لیست تمام کنترلرها و اکشن متدهای یک برنامهی ASP.NET Core
بررسی روش آپلود فایلها از طریق یک برنامهی Angular به یک برنامهی ASP.NET Core
سفارشی سازی صفحهی اول برنامههای Angular CLI توسط ASP.NET Core
تغییرات Encoding در NET Core.
ASP.NET Core Identity
- سفارشی سازی
- امکان ساخت قالب برای پروژههای NET Core.
- تبدیل قالبهای سفارشی پروژههای NET Core. به بستههای NuGet
طراحی یک گرید با Angular و ASP.NET Core
- افزودن و اعتبارسنجی خودکار Anti-Forgery Tokens در برنامههای Angular مبتنی بر ASP.NET Core
- تولید هدرهای Content Security Policy توسط ASP.NET Core برای برنامههای Angular
- غیرمعتبر شدن کوکیهای برنامههای ASP.NET Core هاست شدهی در IIS پس از ریاستارت آن
- اعتبارسنجی مبتنی بر JWT در ASP.NET Core 2.0 بدون استفاده از سیستم Identity
- اعتبارسنجی مبتنی بر کوکیها در ASP.NET Core 2.0 بدون استفاده از سیستم Identity
- فعالسازی HSTS در ASP.NET Core
- مراحل تنظیم Let's Encrypt در IIS
- IdentityServer 4x
- قسمت اول - نیاز به تامین کنندهی هویت مرکزی
- قسمت دوم - ایجاد ساختار اولیهی مثال این سری
- قسمت سوم - بررسی مفاهیم OpenID Connect
- قسمت چهارم - نصب و راه اندازی IdentityServer
- قسمت پنجم - پیاده سازی ورود و خروج از سیستم
- قسمت ششم - کار با User Claims
- قسمت هفتم- امن سازی Web API
- قسمت هشتم- تعریف سطوح دسترسی پیچیده
- قسمت نهم- مدیریت طول عمر توکنها
- قسمت دهم- ذخیره سازی اطلاعات کاربران IDP در بانک اطلاعاتی
- قسمت یازدهم- استفاده از تامین کنندههای هویت خارجی
- قسمت دوازدهم- یکپارچه سازی با اکانت گوگل
- قسمت سیزدهم- فعالسازی اعتبارسنجی دو مرحلهای
- قسمت چهاردهم- آماده شدن برای انتشار برنامه
- قسمت اول - نیاز به تامین کنندهی هویت مرکزی
کار با Areas در ASP.NET Core
کار با کوکیها در ASP.NET Core
بررسی روش آپلود فایلها در ASP.NET Core
ارسال ایمیل در ASP.NET Core
نوشتن Middleware سفارشی در ASP.NET Core
نوشتن TagHelperهای سفارشی برای ASP.NET Core
بررسی تغییرات Reflection در NET Core.
استفادهی گسترده از DateTimeOffset در NET Core.
بررسی روش دسترسی به HttpContext در ASP.NET Core
توزیع پروژههای ASP.NET Core 1.1 بدون ارائه فایلهای View آن
تغییرات رمزنگاری اطلاعات در NET Core.
ساخت بستههای نیوگت مخصوص NET Core.
تهیه قالب برای ارسال ایمیلها در ASP.NET Core توسط Razor Viewها
روش یافتن لیست تمام کنترلرها و اکشن متدهای یک برنامهی ASP.NET Core
بررسی روش آپلود فایلها از طریق یک برنامهی Angular به یک برنامهی ASP.NET Core
سفارشی سازی صفحهی اول برنامههای Angular CLI توسط ASP.NET Core
تغییرات Encoding در NET Core.
تغییرات متدهای بازگشت فایلها به سمت کلاینت در ASP.NET Core
پیاده سازی برنامههای چند مستاجری در ASP.NET Core
مقدمهای بر تزریق وابستگیها درASP.NET Core
نمایش خطاهای اعتبارسنجی سمت سرور ASP.NET Core در برنامههای Angular
احراز هویت و اعتبارسنجی کاربران در برنامههای Angular - قسمت اول - معرفی و ایجاد ساختار برنامه
روش استفادهی صحیح از HttpClient در برنامههای دات نت
اجرای سرویسهای NodeJS در ASP.NET Core
بررسی خطاهای ممکن در حین راه اندازی اولیه برنامههای ASP.NET Core در IIS
تست کردن متدهای یک Controller به کمک PowerShell
کار با Visual Studio در ASP.NET Core
پیاده سازی برنامههای چند مستاجری در ASP.NET Core
مقدمهای بر تزریق وابستگیها درASP.NET Core
نمایش خطاهای اعتبارسنجی سمت سرور ASP.NET Core در برنامههای Angular
احراز هویت و اعتبارسنجی کاربران در برنامههای Angular - قسمت اول - معرفی و ایجاد ساختار برنامه
روش استفادهی صحیح از HttpClient در برنامههای دات نت
اجرای سرویسهای NodeJS در ASP.NET Core
بررسی خطاهای ممکن در حین راه اندازی اولیه برنامههای ASP.NET Core در IIS
تست کردن متدهای یک Controller به کمک PowerShell
کار با Visual Studio در ASP.NET Core
آیا میتوان بدون استفاده از JWT در برنامههای سمت کلاینت هم کار اعتبارسنجی را انجام داد؟
بله. یک نمونه مثال از یک برنامهی Angular که از روش مبتنی بر کوکی ASP.NET Core برای اعتبارسنجی استفاده میکند (بجای استفادهی از JWT).