Can somebody please explain, what the claim mechanism means in new ASP.NET Identity Core?
As I can see, there is an AspNetUserLogins table, which contains UserId, LoginProvider and ProviderKey.
But, I still can't understand or find any information on when data is added to the AspNetUserClaims table and what situations this table is used for?
what does claim mechanism means in new ASP.NET Identity Core?
There are two common authorization approaches that are based on Role and Claim.
Role-Based Security
A user gets assigned to one or more roles through which the user gets access rights. Also, by assigning a user to a role, the user immediately gets all the access rights defined for that role.
Claims-Based Security
A claims-based identity is the set of claims. A claim is a statement that an entity (a user or another application) makes about itself, it's just a claim. For example a claim list can have the user’s name, user’s e-mail, user’s age, user's authorization for an action. In role-based Security, a user presents the credentials directly to the application. In a claims-based model, the user presents the claims and not the credentials to the application. For a claim to have practical value, it must come from an entity the application trusts.
Below steps illustrate the sequence of that happens in a claims-based security model:
But, i still can't understand and find any information, when data addes to AspNetUserClaims and what situations this table using for?
When you are in a situation where a Role-Based Security is not used, and you chose to use Claim-Based Security, you would need to utilize AspNetUserClaims table. For how to use Claims in ASP.NET Identity, see below link for more information.
http://kevin-junghans.blogspot.com/2013/12/using-claims-in-aspnet-identity.html
Update
What time i have to use role-based security and when claim-based? Could you please write a few examples?
There isn't a very clear situation where you would or would not use Role-Based or Claim-Based Security, Not like a case where you would use A rather than B.
But, claim-Based access control allows better separation of authorization rules from the core business logic. When authorization rules change, the core business logic remain unaffected. There will be situations where you might prefer using Claim-Based approach.
Sometimes claims aren't needed. This is an important disclaimer. Companies with a host of internal applications can use Integrated Windows Authentication to achieve many of the benefits provided by claims. Active Directory does a great job of storing user identities, and because Kerberos is a part of Windows, your applications don't have to include much authentication logic. As long as every application you build can use Integrated Windows Authentication, you may have already reached your identity utopia. However, there are many reasons why you might need something other than Windows authentication. You might have web-facing applications that are used by people who don't have accounts in your Windows domain. Another reason might be that your company has merged with another company and you're having trouble authenticating across two Windows forests that don't (and may never) have a trust relationship. Perhaps you want to share identities with another company that has non-.NET Framework applications or you need to share identities between applications running on different platforms (for example, the Macintosh). These are just a few situations in which claims-based identity can be the right choice for you.
For more information, please visit http://msdn.microsoft.com/en-us/library/ff359101.aspx
Just to add more on what @Lin has said above. I am specifically referring to the question:
What time i have to use role-based security and when claim-based? Could you please write a few examples?
I’ve had to add more information to this answer, and this is because I didn’t clearly address the separation between Claim-Based and Role-Based Auth models. From experience and the nature of the concept itself as well presented and documented on Microsoft Docs, the two Authorization models are often used together and an example on when they’re often used together is illustrated on example 3 below. Now let’s discuss the topics in detail:
Claim-Based Authorization:
One important thing to note is that Claim-Based authorization is by nature third-party bound as compared to Role-Based one. Claims are pieces of information provided to you (your app) by a third-party application that describes the user. This information can be anything type of data. Let’s make an example:
Example 1:
Imagined you have a software app that is used to mix songs. And this app basically uses songs from Spotify or YouTube Music platform etc., but it’s built in such a way that it has full access to those platform’s music library. But this app doesn’t require you to sign in with your Spotify or google account, you basically just register with email and password. But after you’re online, to use music from either Spotify or YoutTube music, you’re asked to enter an email address you used to create your sportify or YouTube music account. And then the app requests (via web services) your subscription account number from that respective third-party app and stores it as a claim. So, every time you try to access the music when you’re online, the app uses the registered claim’s policy to check if you have a subscription account and then allow access. The nice thing about this is that the claims are stored with information such as the Issuer where you store where the claim came from. And that’s it. You used a claim, subscriotionAccountNumber, provided by a third-party, that describes you on their side. Obviously, this wouldn’t be the best model to go-about this kind of app but it’s good enough as an example. You’re authorizing your user based on some information about them claimed from another third-party application.
Role-Based Authorization:
This one here is clear enough. At its simplest, You grant access to users based on their Role and their role only.
Example 2:
Imagine an organizational app with multiple users from different positions. You can assign roles to users based on their position and grant access to different information based on their role. Managers, Owners, Employees… Basically not all employees have access to everything Managers and Owners have access to. And this applies to Managers and Owners. Managers are not granted access to some information that only belongs to owners. It’s that simple.
Putting it all together:
In applications like ERP systems, Claims and Roles are used together to build up a complex authorization model. I will always say that The current Identity Framework is so complete that often you don’t need unnecessary extensions that disrupt the existing model, Obviously needs may differ and sometimes breaking the model up could be the only option. When Roles and Claims are used together, Claims serve as Permissions. That is why you have the RoleClaim and UserClaim tables within the model. That is to allow you to extend the authorization beyond the roles themselves. When claims are used together with Roles, they merely provide access to perform certain actions.
Example 3:
Consider a case where you have a clocking system where you have a technician and a manager. At the end of every week, the technician must arrange reports with clocking information showing hours of work artisans worked for that week, which is consolidated and used by payroll. Such systems often must be amended or corrected before final reports are submitted, because you don't want to overpay or underpay your employees. You can use a Role-Based approach for the Manager and Technician by creating a Manager Role and Technician Role. But the Manager Role is the one with the ability to access and edit the clocking information of the artisans. On the other hand, you can have the Technician Role without these abilities to access that information. But Here's the interesting part; A manager can make a claim and allow a technician to access the Clocking Systems and make reports. So a claim can be made only for access without edit or can be made with access and edit capabilities. Remember, only your app understands what your claims mean. They can be named anything, GrantWriteAccess, GrantReadAccess etc, there’s nothing limiting you. After having the claims pre-Defined as permissions, all you need to do is to associate that claim with the user. In this case the Technician would have Both GrantWriteAccess and GrantReadAccess added to their UserClaim table.
This is more like saying, well, By default as the manager I can access some information that my technician can't access. But I am not always around the office? what can I do so that he can still do the work even when I am not around? To solve this the system can have the feature for the managers to create claims(permissions) for people without access to some specific information. We often see these everywhere in our ERP systems. A user without access to some modules and when they get promoted, they're given permission to more modules of the ERP system, sometimes keeping the same user role, and only with some permissions being opened.
Here is a pretty simple explanation from the ASP.NET docs:
When an identity is created it may be assigned one or more claims issued by a trusted party. A claim is a name value pair that represents what the subject is, not what the subject can do. For example, you may have a driver's license, issued by a local driving license authority. Your driver's license has your date of birth on it. In this case the claim name would be DateOfBirth, the claim value would be your date of birth, for example 8th June 1970 and the issuer would be the driving license authority. Claims based authorization, at its simplest, checks the value of a claim and allows access to a resource based upon that value.
It then goes on to give an example that pretty much all of us can understand:
For example if you want access to a night club the authorization process might be: The door security officer would evaluate the value of your date of birth claim and whether they trust the issuer (the driving license authority) before granting you access.
So to answer the question when should I use claims-based security?, the answer is when it's not easy to put people in well defined roles. For example, in the night club scenario, it's too hard to put customers into roles, so you use claims-based access control based on their age as confirmed by their ID (e.g. a driver's license). However in that same night club scenario you can use role-based security to control who has access to which rooms (e.g. using key cards for "staff only" rooms). Clearly you can mix claims-based and role-based security depending on the need.
There are two types of authentication in ASP.Net identity.
You can either use one of them or both at the same time. Use role based when you have very defined things. For example you create two role teacher and student. Only teacher can add subjects. So you assigned teacher role to those users whose you want to have access to add subjects.
Claim based is more flexible. Suppose you have a requirement some students can also add subjects. In this case you have to create one more role who can be student and access to add subject. But if you are using claim based it would be very easy. Just create claim like addSubject and assign it to any user whise you want to access to add aubject.
