Asp.net Core Identity Use AspNetUserClaims or AspN

I am still confused about all this Identity stuff.

First I am still confused the difference between Roles, Policies/Claims. From what I read roles is the old way of doing stuff and was kept for backward compatibility, so does that mean AspNetRoleClaims is part of this backward compatibility?

I think I understand Claims and Policies when thinking of them individual, like policy is basically a set of rules that must pass and gives the ability to change rules without having to go through out all the code and change roles.

Were a claim, is basically a trusted source is vouching for about that user(ie this is their age, which might come from a government source ).

Now what confuses me is putting it all together.

I generated the Identity tables and see

AspNetUsers
AspNetUserRoles
AspNetRoles
AspNetRoleClaims
AspNetUserClaims
AspNetUserLogins

I get what the AspNetUsers table does and AspNetUserLogins(seems to be if they use like external login providers).

I get confused on what the difference between AspNetRoleClaims and AspNetUserClaims. Do I just use AspNetUserClaims or do I use everything?

Say I have this secenario

I have a company that has many branches, in each branch their will be an administrator of that branch, they got full power over the branch and can do anything but nothing at another branch. At the company level there will an administrator who can do anything at the company level and any branch. Finally I have a person in the branch who can just add new employees.

What does this all look like? Do I make 3 roles?

CompanyAdmin
BranchAdmin
AddUsersAtBranchLevel (or is this some sort of claim??)
What do the tables look like? Is there anything going to be in AspNetRoleClaims? AspNetUserClaims?

Now I can make a policy to check if the user is a branch admin and if they are trying to edit their branch?

Or do I just forget all the role stuff and have in the AspNetUserClaims

User1   CanAddUserToBranch true
User1 CanDeleteUserBranch true
User1 CanAddUserToCompany true

Then in my code make those all different "ClaimTypes" and create a polciy that sees if they have say "CanAddUserToBranch" and then another claim or policy to check what branch they are in to make sure they are trying to add something to the right branch?

Edit

Do you think I Need to use Resource-based authorization?

+------------------+------------------+
|      Table       |   Description    |
+------------------+------------------+
| AspNetUsers      | The users.       |
| AspNetRoles      | The roles.       |
| AspNetUserRoles  | Roles of users.  |
| AspNetUserClaims | Claims by users. |
| AspNetRoleClaims | Claims by roles. |
+------------------+------------------+

A role is something assigned to a user.
- Eg. Jane is an admin.
A claim is something claimed by a user.
- Eg. Jane's date of birth is 1990-10-1.
A role-claim is a claim claimed by a role.
- Eg. Admins have access to the dashboard.

If you find roles and claims confusing, it's probably because roles are a special case of claims i.e. roles are claims.

Role vs Policy

For role based authorization, the authorization system checks if the user has been assigned the roles required to access the given resource.
- Eg: only users with the Admin role can access the dashboard.
For policy based authorization, some business logic is executed to decide if the resource access should be authorized.
- Eg: only Admins with an age above 40 can access financial data.

Say I have this scenario

I have a company that has many branches, in each branch their will be an administrator of that branch, they got full power over the branch and can do anything but nothing at another branch. At the company level there will an administrator who can do anything at the company level and any branch. Finally I have a person in the branch who can just add new employees.

Here's one way of doing it:

2 roles: Admin, TheRoleThatCanAddUsers
A claim called Branch that can take a branch id (or anything else to identify the branch). Company admins can use a value like "CompanyWide" or 0 or -1.

Now create a policy that checks the Role and the Branch claim and decides if the user should be authorized.