问题
I have slight architecture issue. I have IdentityServer solution, to authenticate user with Identity user store(with user in database). I have login functionality here and register functionality, so I have to use DbContext here. I have another solution API where I hold custom tables which are not Identity tables. All tables are in same database.
Now when I add new record through API, I somehow want to connect CreadetBy with Identity user. I know I can get info about user from Claims, and then insert while creating new row, but is that good practice?
Another question is, should I move registration operation out of IdentityServer project, and only use Login functionality towards identity user store there and put registration to API, so I don't duplicate additional fields for ApplicationUser in two places?
回答1:
From what I understand you should maintain a seperation of concerns. You should never have a relation between tables that do not share the same context. This means that Cars can never link to AspNetUsers.
It is about the meaning of the objects and the fields. For example, it seems that IdentityUser and CustomUser are equal, but they are not. The IdentityUser has all the information needed to identify the user as where CustomUser has all the information needed for the custom model. In fact, you can have CustomUsers which do not have a login account.
Also consider the emailaddress. It seems redundant to have this field in both contexts, but actually I could use my Google account to login while I want to receive updates on my custom emailaddress.
So what is the meaning of the CreatedBy field and how are you going to use it? If it is part of the custom context (like for reports), then you should have a CustomUser table and relate to that table. If you just want to check this for administration purposes, than it may suffice to store the username. Are you going to query by that field? Do you need additional information, like CustomUserAddress?
If done well, I don't think you actually have redundant fields. Since they all have different purpose / meaning.
In any case, you don't want to relate beyond the context. And you don't want to end up sending lists of id's to retrieve information from another context.
The problem is that you want to link the current user. The identity token is used to identify the user. This means nothing to your resource. But the access token contains information about the actual user in the resource.
By keeping authorization close to the resource, you can extend the authorization user with CustomUserId. Add this information to the access token, since it is part of the authorization. It tells the resource that the user can only access data from the specified user.
With [access token].customUserId you can match the CustomUser. Thus CreatedBy should have the value of CustomUser.Id.
I would also like to recommend this article: https://leastprivilege.com/2016/12/16/identity-vs-permissions/
来源：https://stackoverflow.com/questions/44096327/can-i-use-claims-data-to-insert-createdby-user-data-into-custom-tables