Security architecture in ASP.NET Core

In ASP.NET Core, the authentication is implemented as middleware. With previous versions of ASP.NET Security, there was only a FormsAuthentication cookie, but with the new ASP.NET Core Identity system, multiple cookies can be defined. Different authentication providers are provided and, instead of only authenticating users from the local identity data store, we can also authenticate users from external providers such as Microsoft account, Google, Facebook, and Twitter.

Everything in the new Identity system is based on claims. That means all properties on the user's identity object are now defined through claims. Properties such as name, e-mail, department, role, designation, and many others, are a few examples of the common properties associated with the user's identity and we can use these properties to authorize user permissions. ClaimsPrincipal is the main class through which claims can be defined. However, implementing custom claims through the IPrincipal interface is now deprecated.

Encoding sensitive information is often needed in many web applications. Through new cryptographic protection APIs, developers can easily encrypt information, and they provide support key management and rotation. The core of the ASP.NET data protection stack is the replacement for the <machineKey> element that we used to have in previous versions of ASP.NET.

Cross Origin Request Sharing (CORS) prevents a web page from making AJAX requests from client-side scripting languages such as JavaScript. With ASP.NET Core, enabling CORS and allowing request and response headers, HTTP methods, and origin is much easier and simpler than before.

Another core component is logging, which is included by default with ASP.NET Core. You can start logging by simply creating a logger instance using LoggerFactory and also develop and implement custom loggers to log information in the database or any other medium.

One of the most common types of attack on websites is referred to as cross-site request forgery (known as CSFR or XSFR). This happens when a user accesses some malicious website or opens up some malicious e-mail that contains some script and submits harmful requests on a site where the users are authenticated. This way, the malicious site forges requests, as they appear to come from a legitimate user. The forged request then attempts to impersonate authenticated users and performs an activity. To prevent these attacks, we can add anti-forgery middleware in the application pipeline and it does all the plumbing to verify whether the request is coming from the same user as it should be.

Now, let's discuss some of the core API's of the Identity system.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.129.211.166