If you are only ever going to have types of users where it is ok for all users of a given type to have the same permissions (and not for example for the permissions to vary by user for different data records), then you are effectively doing the same as if you were using Roles based permissions rather than Claims based ones.
The point of using Claims is that it allows you to do everything you could do via Roles and more. Claims give you more flexibility: e.g. your database could contain data for several different clients (ClientA and ClientB), each of whom could have an Admin user (eg AdminUserA, and AdminUserB) but who only have admin rights over records related to the particular client they belong to.
In that situation you could achieve this by giving user AdminUserA a claim of type ClientA with value Admin, and user AdminUserB a claim of type ClientB with value Admin. Then in code you would only allow users with a claim value of Admin for claim to administer records for client with clientname .
See my comment on How to add claims in ASP.NET Identity for two different ways of adding a claim to a user (unfortunately, Microsoft don't seem to have documented this well, so it is unclear as to whether both methods are needed!). As mentioned there, you can add a claim to the AspNetClaims table (but not to cookies) via manager.AddClaim(userID, claim) in GenerateUserIdentityAsync(UserManager manager) for class ApplicationUser within IdentityModel.cs (within an MVC5 project).
You can check what claims a user has as follows:
When the user logs in, userIdentity.Claims should contain all the claims the user has (including custom claims that were in the AspNetClaims before the user logged in, but not any added since via manager.AddClaim!), and manager.GetClaims(userID) should return all the user's custom claims (including ones added via manager.AddClaim!). This is messy, and Microsoft really ought to tidy this up or at least document it better!
Hope this helps