Skip to main content

ASp.net core 3.1 identity

It is just an extension to cookie authentication. We get a UI, Tables, helper classes, two factor authentication etc. Even EF and its database constructs.

So instead of writing code for all of this we can just use these in built features.

Extending Default Identity Classes

Add a class that inherits from 

 public class AppUser : IdentityUser
    {
        public string Behavior { get; set; }
    }


Also change the user type in login partial.cs under shared folder






Then add migrations and update db using migrations. We can customize further.

 services.AddDefaultIdentity<AppUser>(options => 
            {
                options.SignIn.RequireConfirmedAccount = true;
                options.Password.RequireDigit = false;
            })



   .AddEntityFrameworkStores<ApplicationDbContext>(); -- Tells Identity to use this context.



 app.UseAuthentication(); -- configures cookie  based auth 

Identities UI

No UI pages are there in the project instead its in a nuget package.




Adding Identity to existing project






A text file named ScaffoldingReadMe.txt will be created.  Follow all the instructions and make the changes. The new DBContext will be added in the Areas folder and connection string will be added to the appsettings.json file.

IdentityHostingStartup.cs . This class works as a combination of both configure and configureservices inside startup.cs. We can copy them to startup also if needed. This class is called everytime the application starts. Also check out these files.



















The razor pages dont have a controller, the code is in written as codebehind. In order to add more claims to the ClaimsPrincipal or to return more claims in the cookie, just add the new claims to the aspnetclaims table. Or 


public class AppNewUserCLaims : UserClaimsPrincipalFactory<ConfArchWebUser>
    {
        public AppNewUserCLaims(UserManager<ConfArchWebUser> userManager, IOptions<IdentityOptions> options)
            : base(userManager, options) => (_userManager, _options) = (userManager, options);

        public UserManager<ConfArchWebUser> _userManager { get; }
        public IOptions<IdentityOptions> _options { get; }

        protected override async Task<ClaimsIdentity> GenerateClaimsAsync(ConfArchWebUser user)
        {
            var identity = await base.GenerateClaimsAsync(user);

            // Add custom claims to the cookie
            identity.AddClaim(new Claim("FullName", user.FullName));

            return identity;

        }

    }


Inject it into the container.

 services.AddScoped<IUserClaimsPrincipalFactory<ConfArchWebUser>, AppNewUserCLaims>();

Or while creating a new User just add the claims to the AspnetClaims table, this will be included by default..


ROLES

Roles are added as claims. So if a user has 2 roles then they will be added to the claims lists




1.Add role to AspNetRoles

2. Asoociate that role to a user in AspNetUserRoles



EXTERNAL LOGINS

For external logins we can just add to IdentityHostingStartup

services.AddAuthentication()
                .AddGoogle(options =>
                {
                    options.ClientId = "xxxxxx";
                    options.ClientSecret = "xxxxxxxxxx";
                });

We can link local logins to google logins. 




Comments

Post a Comment

Popular posts from this blog

Az-500 NSG and ASG

Application security groups Application security groups enable you to configure network security as a natural extension of an application's structure, allowing you to group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without manual maintenance of explicit IP addresses. The platform handles the complexity of explicit IP addresses and multiple rule sets, allowing you to focus on your business logic. To better understand application security groups, consider the following example: In the previous picture,  NIC1  and  NIC2  are members of the  AsgWeb  application security group.  NIC3  is a member of the  AsgLogic  application security group.  NIC4  is a member of the  AsgDb  application security group. Though each network interface in this example is a member of only one network security group, a network interface can be a member of multiple app...

App Role assignment to service principal --

 Using Ms Graph Rest API's Permissions One of the following permissions is required to call this API. To learn more, including how to choose permissions, see  Permissions . Permission type Permissions (from least to most privileged) Delegated (work or school account) AppRoleAssignment.ReadWrite.All and Application.Read.All, AppRoleAssignment.ReadWrite.All and Directory.Read.All, Application.ReadWrite.All, Directory.ReadWrite.All Delegated (personal Microsoft account) Not supported. Application AppRoleAssignment.ReadWrite.All and Application.Read.All, AppRoleAssignment.ReadWrite.All and Directory.Read.All, Application.ReadWrite.All, Directory.ReadWrite.All Create 2 app registrations. App role owner will contain the app role that will be assigned to a service principal. The  reader role in approleowner will be added to the approlesubscriber Setup postman to use the Oauth auth flow to get a token for MS Graph. ClientId:   Application (client) ID for approlesubscrib...