IdentityUserClaim type hardcoded into UserStore

[slaneyrw]

I'm investigating moving a MVC 5 app with Asp.NET identity v2 to MVC 6 and Identity v3 and I have noticed an issue with User Claims.

In our existing application we're using the 5 type generic argument of UserStore to change the TUserClaim type from IdentityUserClaim to a subclass of IdentityUserClaim that adds a Issuer property (string) to the data schema, mapped to the Issuer property of a Claim.

The reason we need this is that we need to disambiguate claims from another identity provider and using the Issuer property of a claim allows us to do that.

However in v3, it appears IdentityUserClaim type is impossible to replace so that all claims mapped from the User type to the internal claimstore (for persisting) will go via the IdentityUserClaim type and therefore it is not possible to extend the AspNetUserClaims table with an Issuer property.

Short of replacing the entire UserStore, is there another approach I can use ?

Can you extend the IdentityUserClaim object to include the Issuer property ?

[HaoK]

Unfortunately no, we decided that its pretty easy to implement a store for this scenario, and you can mostly just reuse the existing UserStore code.

[slaneyrw]

Ok, so I'll override all 5 IUserClaimStore<TUser> functions on UserStore<TUser, TRole, TContext, TKey>, but what TContext do I use ? As the IdentityDbContext<TUser, TRole, TKey> has also hardcoded IdentityUserClaim into it's model (OnModelCreating), so I have to replace the entire IdentityDbContext as well.

i.e.
IdentityDbContext<TUser, TRole, TKey>.UserClaims : DbSet<IdentityUserClaim<TKey>>

[slaneyrw]

Oh, and I've just discovered ( as I was trying to implement by own DBContext, IdentityUserClaims is exposed directly off IdentityUser as well, meaning I have to replace IdentityUser as well, essentially the entire object graph.

modelBuilder.HasMany<IdentityUserClaim<TKey>>( user => user.Claims )

...then...

If you replace IdentityUser you can no longer subclass UserStore because of TUser generic constraint, that's a lot of code to replace;

[tlogik]

I have the same issue.Replacing all that code seems to be very counter productive.
Could a better approach possible be considered?