How to manage user claims?

Question

I'm currently designing a system using asp.net core and I'd like to implement claims based authorization, but one particular part is confusing me.

When a claim is made the claim will include the type and the value and optionally an issuer. In a handler this claim and the issuer may be checked before access is confirmed.

However this issuer is not stored in the Identity db, so how does the handler then check the issuer?

Am I misunderstanding how this all works? My understanding was that a user makes a claim of some type, that their claim is of a certain value and the issuer is the validator of the claim type actually having that value for that user.

The handler will check the value and may check the issuer but it can't when the db does not store it. I don't understand the point of the issuer then.

I'd like the user to have a collection of claims, including who/what verifies those claims and for the application to at any time be able to verify those claims.

Please help me understand.

I have tested this as so:

1. Using a asp.net core app with Identity.
2. Register a user.
3. Add a claim to a user that includes a type, a value and an issuer. (for example, EmployeeNumber, 312, Microsoft.
4. Add an [Authorize(Policy="MicrosoftEmployeesOnly")] on a controller/action to restrict access.
5. Add the policy into services in StartUp.cs with a requirement.
6. Add requirement code that has a handler that checks the user has a claim of type EmployeeNumber, has a value and it is issued by Microsoft.
7. Login and the users claims will have been loaded in from the db into the identity.
8. The handler will fail to validate the user because the issuer (Microsoft) has been lost and now just says Local Authority.

The only thing I can think of here, is once the claim is added in to the db, it is considered validated by Microsoft and now held by the app (Local Authority) on behalf of Microsoft.

If that's true then:

1. Why check the issuer at all in any handler?
2. How do you revoke a claim?

I would prefer to be able to optionally go to that issuer and check the claim whenever I want, meaning the issuer could revoke/invalidate the claim. The employee makes the claim they have an employee number at Microsoft and initially Microsoft validate that. Some time later, Microsoft kick the employee out and on their system remove him. The app should be able to check with Microsoft each time the user logs in to see if the claim is valid. In this case it would not be valid any more.

Am I going slightly mad?

Answer 1

Posting this here as you linked to this question from my blog , and it may be useful to someone

I think you have misunderstood slightly about the nature of a claim, which I can understand given the terminology. You seem to be taking 'Claim' as meaning the user is 'professing' that they have a certain attribute, and you want to check that this is true.

That is not the way claims work here. Claims are essentially 'attributes' of the user. In the old way of working with roles, a user would belong to a certain number of roles. These are just 'attributes' the user has now, so are more generic. A user may have a number of claims corresponding to the roles they are in.

The identity of the user is checked during authentication, and at that point you assign the set of Claims that the user has to the ClaimsIdentity object. This is the point you fetch the claims from the database, and make sure they only get the ones they should have. If you need to have someone verifying claims, then you would need to have that whole process happening outside of this. Only the claims which have been confirmed should be added to the ClaimsIdentity .

Now, there is an event you can handle on the CookieAuthenticationMiddleware to validate a security ticket when it is loaded on subsequent requests called ValidatePrincipal, but I'm not sure if this is actually what you need.

And your subsequent response:

Thank you for your response. I understand now that these claims are effectively verified claims once they get into the db. I guess they could be removed from the db as a way of revoking the claim.

However, I think, as you suggest, the best way is to have this system outside and it just provides claims as and when required. The design is that the application will have accounts for different types of entity and accounts will be able to make claims, for example that "I am a parent". The parent would seek an authorizing account to validate this. This might require the authorizing account holder to actually see some real documentation before validating. Other claims, could change. For example a parent with Parental Responsibility would need a bit more verification, but may also lose that Parental Responsibility in the real world and so a facility for revoking the claim needs to be available.

So, I think the design should be to use the claims system with the Authorize attribute following your excellent articles, but have a separate system that allows for validation and revoking that feeds that claims system.