I am spending time these days to analyze and understand some implementation details that drive the identity for ASP. And one particular implementation really caught my mind, I am not saying it’s right or wrong, but it’s something to be aware of:
The UserStore and the UserOnlyStore give you all the functionality you need for the UserManager to be used in your ASP project. This store implements all the required functionality for most of the identity requirements.
The interface IUserClaimStore exposes the following methods:
As you can see, this method does not work with derivates of the IdentityUserClaim model, and it’s a perfect approach since it leaves the choise to the developer to use a different class if he needs, and the implementation details will convert Claim to the Database model Claim. In the EF implementation this model is a derivative if the IdentityUserClaim
The IdentityUserClaim has a very simple implementation, same as ClaimLite or ClientClaim from IdentityServer with the difference that this has the UserId in the model.
What you can see from the above model is that Issuer is not defined in the database model, and without an issuer I don’t really see any reason why a user should have more values for any given type, providing that are do not use claims to define complex array objects with types as a dictionary key, right?
Having this in mind, there are 2 questions that for me are unclear at this point:
- IdentityUserClaim is extensible, and should I decide to use the Issuer property then I can justify having multiple values per type provided by the multiple sources. (Facebook GivenName, Google GivenName, and so on). This check and how it’s implemented has no way of verifying that, and I think the responsability should be moved in the IdentityUserClaim model.
Original:
My idea of it: - Why should the value be checked? We are replacing a claim with another claim, we are not replacing a pair claim-type-value with a new claim.Perhaps some of these questions will be clarified,I’ll keep you posted.
