Prep Authentication, Authorization, & Identity

Authentication is the process of validating a user that he/she is whomever he/she says they are.

Authorization is the process of determining if a particular user that has been authenticated, has rights to particular resources.

ASP.NET Core Identity is a library (API) called 'using 'Microsoft.AspNetCore.Identity' that supports user login functionality. It supports users, profiles, passwords, roles, claims, tokens, email confirmations, and more.

Using a .NET Core application, make the following changes to include Identity tables.

• 1. Using NuGet, add the Microsoft.AspNetCore.Identity.EntityFrameworkCore library to your project
• 2. In the AppDbContext.cs context file, change the DbContext superclass to use the IdentityDbContext class instead 
• 3.  In the OnModelCreating() function, pass the modelBuilder variable to the base class [base.OnModelCreating(mb);]
• 4. In StartUp.cs file, add a new service to allow Identity handling with AppDbContext file. This service will use both IdentityUser and IdentityRole classes (see *)
• 5. Add middleware authentication to our pipeline (see *)
• 6. Use Package Manager to create and update a new migration script which will add these tables to our database.

• services.AddIdentity<ApplicationUser, IdentityRole>()
• .AddEntityFrameworkStores<AppDbContext>();

app.UseAuthentication();

We have 7 new tables, called

• dbo.AspNetRoleClaims
• dbo.AspNetRoles
• dbo.AspNetUserClaims
• dbo.AspNetUserLogins
• dbo.AspNetUserRoles
• dbo.AspNetUsers
• dbo.AspNetUserTokens

• 1. Create a RegisterViewModel class with Username, Password, and ConfirmPassword values.
• 2. Create a controller called AccountController and, using DI, inject UserManager and SignInManager 
• 3. Create two action methods, one to collect data and the other to post. With the post, we create a new IdentityUser and attempt to create this new user with the userManager.CreateAsync() call, if we are successful, then sign them into the system using signInManager.SignInAsyc().
• 4. We will need sign in awareness everywhere in application, so add the @using Microsoft.AspNetCore.Identity to the _ViewPort.cshtml page.
• 5. Create a new Register.cshtml page with our model
• 6. On our _Layout.cshtml page (contains our toolbar), we want to include the '@inject SignInManager<IdentityUser> signInManager' statement at the top of file so we can view email, username etc on the toolbar

• 1. Create a LoginViewModel class with Username, Password, RemembeMe properties
• 2. Create a View called Login.cshtml providing basic validation and a post to controller.
• 3. In controller, create two methods using HttpGet and HttpPost and with this second one, attempt to sign in the user by using the _signInManager.PasswordSignInAsync() with username, password, persistance flag, and lockout flag.
• 4. If successful, redirect user to home, otherwise add our error to the ModelState and reload view.

Provide a button which posts a form page to the account/logout action method using the @User.Identity.Name claims principle. In this method, call the _signInManager.SignOutAsync() method and it will sign out the current user (no name needed) then redirect to home screen.

Ability to allow users to login to our application using external authentication and not our own application.

Companies include Facebook, Google, Microsoft, Twitter, and many more.

1. We first obtain a key from Google, Twitter, or whomever as well as their sign-in path and return Url (ie, https://localhost:44312/signin-google), we save these as secrets for security reasons.

2. Install the associated API library, such as Microsoft.AspNetCore.Authentication.Google

3. Add the service to the project, providng our clientId and clientSecret.

• services.AddAuthentication().AddGoogle(options =>
•      {
•        IConfigurationSection googleAuthNSection = COnfiguration.GetSection("Authentication:Google");
•      options.ClientId = googleAuthNSection["clientId"];
•      options.ClientSecret = googleAuthNSection["ClientSecret"];
•      }

OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. Companies include Facebook, Microsoft, Google, Twitter, and more.

You run your application which allows for OAuth authentication. An option is provided to the user to sign in using Google, Facebook, or whomever, the user clicks the button and is redirected to associated company for signin. Once properly authenticated, the user is redirected back to original website.

1. Cross-site scripting (xss attaccks): Cross-Site Scripting (XSS) is a security vulnerability which enables an attacker to place client side scripts (usually JavaScript) into web pages. When other users load affected pages the attacker's scripts will run, enabling the attacker to steal cookies and session tokens, change the contents of the web page through DOM manipulation or redirect the browser to another page. XSS vulnerabilities generally occur when an application takes user input and outputs it to a page without validating, encoding or escaping it.

2. SQL Injection 

3. Cross-site request forgery

4. Open redirect attack

Once a user has been authenticated, we can choose either role-based or claims-based authorization to work with resources. Note however, that Microsoft suggests using claims-based as it is newer.

Yes, most companies use a role-based hierarchy such as Accounts, Managers, EndUsers, Reports, ets.

We typically call these on our controllers using [Authorize(Roles = "Admin, Reports")]

Claims-based identity uses name/value pairs and has the potential to simplify authentication logic for individual software applications, because those applications don't have to provide mechanisms for account creation, password creation, reset, and so on. Furthermore, claims-based identity enables applications to know certain things about the user, without having to interrogate the user to determine those facts. The facts, or claims, are transported in an "envelope" called a secure token.

A single sign in creates the token which is then used to authenticate against multiple applications, or web sites.

• STEP 1: services.AddAuthorization(options => 
• {
•      options.AddPolicy("DeleteRolePolicy",
•      policy => policy.RequireClaim("Delete Role");
• });

• STEP 2: 
• [Authorize(Policy = "DeleteRolePolicy")]
• public async Task<IActionResult> DeleteRole(string id)
• {
•      // delete role
• }

We can use Immediate Window and use the User.Claims object, for example, to see roles claims:

User.Claims.Where(m => m.Type == ClaimTypes.Role)

Using this, we might see we are returned both Admin and Reports

[Authorize(Role = "Admin, User")]

[Authorize(Policy = "DeleteUserPolicy")]

In the UI, we use the "@using Microsoft.AspNetCore.Identity"  API coupled with the @inject SignInManager<ApplicationUser> signInManager.

We then add our basic logic, like so:

• @if (signInManager.IsSignedIn(User) && User.IsInRole("Admin"))
• {
•   // show our toolbar item
• }

In the UI, we use the  "@using Microsoft.AspNetCore.Authorization" API coupled with the @inject IAuthorizationServer authorizationService command.

We then add our basic logic, like so:

• @if ((await authorizationService.AuthorizeAsync(User, "EditUserPolicy")).Succeeded)
• {
•   // show our edit button
• }

No, this isn't enough security, a savvy user could bypass this capability and simply use the URL to navigate to the controller where he/she could then manipulate (Edit) the user if no authorization prevented the user from doing so.